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1.  Introduction 

A  major  part  of  database  research  over  several  years  has  been  the  design  and  analysis  of  algorithms  to 
maintain  consistent  data  in  the  face  of  interleaved  accesses,  aborts  of  operations,  replication  of 
information  and  failures  of  system  components.  The  most  popular  and  simple  protocol  is  two  phase 
locking  with  separate  read  and  write  locks;  other  methods  include  arbitrary  conflict-based  locking, 
timestamp)- based  techniques,  and  locking  that  uses  special  structure  of  the  data  (e.g.  a  hierarchical 
arrangement)  [Gr,T,KS,Ko,We].  A  powerful  theory  has  been  developed  to  prove  the  correctness  of  these 
algorithms,  based  on  the  idea  that  a  protocol  is  correct  if  it  ensures  that  all  executions  are  equivalent  to 
serial  executions  [EGLT,P,BG].  This  theory  proves  serializability  by  showing  that  a  precedence  graph 
contains  no  cycles. 


Recently,  some  ideas  in  database  system  design  and  more  general  distributed  system  design  have  led 
several  research  groups  to  study  the  possibility  of  giving  more  structure  to  the  transactions  that  are  the 
basic  unit  of  atomicity.  When  a  transaction  can  contain  concurrent  operations  that  are  to  be  performed 
atomically,  or  operations  which  can  be  aborted  independently,  we  say  that  the  operations  form 
subtranaactions  of  the  original  transaction.  Thus  we  consider  a  system  where  transactions  can  be  nested. 
This  idea  was  first  suggested  by  Davies  under  the  name  spheres  of  control  [D).  A  primitive  example  of 
this  concept  is  implemented  in  System  R,  where  a  recovery  block  can  be  aborted  and  the  transaction 
restarted  at  the  last  savepoint.  In  general  distributed  systems  like  Argus  |LiS,LHJLSW)  or  Clouds  |A],  the 
basic  services  are  often  provided  by  Remote  Procedure  Calls  which,  at  their  best  ("At  Most  Once" 
semantics),  are  atomic.  Since  providing  a  service  will  often  require  using  other  services,  the  transactions 
that  implement  services  ought  to  be  nested. 


The  implementation  of  a  nested  transaction  system  requires  extending  the  algorithms  that  have 
previously  been  considered  for  concurrency  control,  recovery  and  replication.  The  work  of  Reed  (Rj 
extended  multi-version  timestamp  concurrency  control  to  provide  nested  transaction  data  management. 
Moss  [Mo]  extended  two  phase  locking  with  separate  read  and  write  locks  to  handle  nesting,  and  this 
algorithm  is  the  basis  of  data  management  in  the  Argus  system  implemented  at  MIT. 


This  paper  is  part  of  a  major  research  effort  to  offer  clean,  readable  descriptions  of  algorithms  for 
managing  data  in  a  nested  transaction  system,  together  with  rigorous  proofs  of  the  correctness  of  these 
algorithms.  Other  parts  of  the  project  include  studying  replicated  data  management  algorithms,  orphan  : 
elimination  algorithms  and  general  atomicity  of  abstract  objects.  All  this  work  is  based  on  a  simple  model 
of  concurrent  systems  using  I/O  automata  and  an  operational  style  of  reasoning  about  their  schedul“s. 
The  first  fruits  of  this  program  are  detailed  in  [LM],  which  proves  the  correctness  of  exclusive  locking, 
and  provides  a  basic  framework  for  presenting  t!ie  ideas  of  this  p.aper 
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This  paper’s  contribution  is  threefold.  First,  it  proves  for  the  first  tune  the  correctness  of  Moss' 
algorithm,  an  algorithm  which  has  been  used  in  practice.  Our  discussion  covers  both  concurrency  control 
and  recovery  from  aborts.  However,  we  do  not  consider  all  the  failure  cases  that  the  real  systiin  must 
deal  with,  as  our  model  does  not  yet  include  crashes  that  compromise  the  system  state.  Second,  we 
provide  technical  definitions  (for  equief fectiveneae  and  traneparency)  that  seem  to  capture  exactly  those 
properties  of  read  operations  depended  on  by  the  algorithm.  Third,  this  paper  provides  another  example 
of  the  power  and  value  of  the  basic  model  of  serial  correctness  first  proposed  in  [LMj,  and  of  the 
operational  style  of  reasoning  with  I/O  automata. 

In  this  paper  we  first  review  the  I/O  automaton  model  of  computation.  This  is  very  similar  to  models 
like  Communicating  Sequential  Processes  [Ho],  in  th.at  automata  inter.-ic',  by  synilucniziiig  on  shared 
operations.  The  main  difference  from  other  models  is  that  we  distinguish  the  input  and  output  operations 
of  each  automaton.  Any  operation  shared  between  components  of  a  system  can  be  an  output  of  at  most 
one  component,  and  that  component  is  in  control  of  the  operation,  because  no  automaton  is  allowed  to 
refuse  to  execute  an  input.  Though  automata  have  states  as  well  as  operations,  we  concentrate  our 
analysis  on  the  sequence  of  operations  performed  (the  schedule  of  the  system)  -  this  operational  mode  of 
reasoning  is  quite  different  from  assertional  invariant  methods  used  elsewhere  in  reasoning  about 
distributed  systems,  but  we  find  it  very  powerful  and  yet  simple  for  the  set  of  problems  we  consider. 

Next,  we  show  how  to  use  I/O  automata  to  model  the  parts  of  a  nested  transaction  system.  Each 
transaction  is  represented  by  an  automaton,  as  is  each  data  object.  The  actions  of  calling  a 
subtransaction,  invoking  an  access  to  an  object,  and  returning  a  result  are  each  split  into  two  operations, 
one  requesting  the  action  and  one  delivering  the  request  to  the  recipient.  The  request  operation  is  an 
output  of  the  caller  and  an  input  to  the  scheduler  (which  acts  as  a  communication  system)  while  the 
delivery  operation  is  an  output  of  the  scheduler  and  an  input  of  the  recipient.  Thus,  each  transaction 
(and  each  object)  shares  operations  only  with  the  scheduler.  A  serial  system  is  the  result  of  composing 
transaction  and  object  automata  with  a  serial  scheduler,  which  runs  the  subtransactions  of  any 
transaction  sequentially  (with  no  concurrency  between  siblings)  and  only  aborts  transactions  before  they 
start  running.  The  serial  scheduler  is  very  simple  to  understaini  and  is  iisi  d  as  the  basis  of  our  correctness 
condition. 

We  then  introduce  a  R/\V  Locking  system  to  model  a  system  using  Moss’  locking  algorithm  to  tn.an.ige 
data.  We  use  a  new  sort  of  I/O  automaton  called  a  M'  Locking  object,  whicli  i.s  like  the  object 
automaton  of  the  serial  system,  but  which  maintains  leek  t.-tbles  an<l  \ersinns  of  ibe  obii-  t  so  ilmt  it  can 
respond  correctly  when  aborts  occur.  It  also  delays  o|)eration.s  until  it  i.s  permitted  to  r-spond  by  the 
locking  rules.  We  also  use  a  new  sort  of  scheduler  called  a  generic  srhedultr.  which  transmits  rfspiests  to 
the  appropriate  recipient  with  arbitrary  delay,  allowing  siblings  to  run  concnrieniK  r,  .iIkui  after 


performing  some  work.  A  R/W  Locking  system  is  the  result  of  composing  the  transaction  automata, 
R/W  Locking  objects  and  gen''ric  scheduler 

A  R/W  Locking  system  allows  more  concurrency  than  a  serial  system,  but  it  is  correct  in  the  sense  (first 
suggested  in  [LM])  that  each  transaction  that  does  not  have  an  aborted  ancestor  is  unable  to  tell  whether 
it  is  running  in  a  R/W  Locking  system  or  in  a  serial  system.  The  proof  of  this  correctness  condition  is 
the  main  result  of  this  paper. 

The  proof  proceeds  by  taking  an  arbitrary  schedule  of  a  R/W  Locking  system  (a  concurrent  schedule) 
and  explicitly  showing  how  to  rearrange  the  operations  to  get  a  schedule  of  the  serial  system.  The 
permitted  rearrangements  (which  do  not  alter  the  sequence  of  events  at  any  transaction)  are  those  that 
are  write-equivalent  to  the  original  sequence. 

A  key  contribution  of  this  paper  is  in  identifying  exactly  the  properties  of  read  and  write  accesses  that 
are  required  to  guarantee  correctness  of  Moss’  algorithm.  Write  accesses  require  no  special  properties. 
However,  it  is  necessary  that  read  accesses  leave  the  object  in  "essentially"  the  same  state  as  they  found 
it.  We  define  equief fective  schedules  to  be  those  that  leave  the  object  in  "essentially"  the  same  state, 
where  "essentially"  means  "as  far  as  later  operations  can  detect".  Then  an  object  schedule  with  a  read 
access  appended  is  required  to  be  equieffective  to  the  same  schedule  without  the  read  access. 

There  have  been  several  other  attempts  to  provide  rigorous  proofs  of  the  correctness  of  algorithms  for 
data  management  in  nested  transaction  systems.  The  first  was  [Ly],  which  presented  a  model  that 
successfully  handled  exclusive  locking,  but  which  proved  difficult  to  extend  to  more  '.omplicated  problems 
such  as  orphan  elimination  [Go].  The  main  deficiencies  of  this  earlier  model  seem  to  be  the  lack  of 
distinction  between  inputs  and  outputs,  and  the  lack  of  explicit  representations  for  transactions  and  their 
interfaces.  These  deficiencies  were  remedied  in  |LM],  where  the  operational  model  discussed  above  was 
defined;  this  paper  again  proved  correctness  of  exclusive  locking.  This  paper  continues  the  work  of  [LM] 
by  dealing  with  an  algorithm  with  separate  read  and  write  locks.  (T  ?  result  of  this  paper  imp''*>s  a  main 
result  of  [LM],  since  when  no  accesses  are  distinguished  as  read  accesses.  Moss’  algorithm  degenerates  into 
exclusive  locking.)  A  different  program  to  study  concurrency  control  in  nested  transaction  systems  has 
been  offered  in  [BBGLS,BBG],  where  a  major  motivation  is  to  analyze  protocols  that  operate  on  data  at 
different  levels  of  abstraction,  but  where  recovery  is  not  considered.  The  argument  for  the  correctness  of 
Moss’  algorithm  in  [BBG]  considers  only  the  locking  rules  and  not  the  state  maintenance  methods,  so 
correctness  is  proved  only  in  the  absence  of  aborts.  Concurrency  control  and  recovery  algorithms  are  also 
analyzed  in  [MGG],  but  [MGG]  is  also  concerned  mainly  with  levels  of  abstraction. 

This  paper  uses  many  concepts  from  [LMj,  but  we  have  repeated  everything  needed  to  make  it  self- 
contained,  and  indicated  where  definitions  or  details  differ.  In  Section  2,  we  review  the  model  of  1/0 
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automata  of  [LT,LM].  In  Section  3,  we  define  the  automata  that  make  up  the  serial  system,  namely  the 
transaction  automata,  the  basic  object  automata  and  the  serial  scheduler.  In  Section  4,  we  specify  the 
semantic  conditions  that  read  accesses  must  satisfy,  using  the  technical  notion  of  equieffeclive  schedules. 
In  Section  5  we  define  the  automata  of  the  R/W  Locking  system,  namely  the  R/W  Locking  objects  (which 
have  code  based  directly  on  the  algorithm  of  [Mo])  and  the  generic  scheduler,  and  prove  the  main  lemmas 
that  relate  the  schedules  of  R/W  Locking  objects  to  the  schedules  of  the  basic  objects.  Finally  in  Section 
6  we  prove  that  R/W  Locking  systems  are  serially  correct  at  tr.ansactions  no  ancestor  of  which  has 
aborted,  and  in  particular  at  the  root  transaction  which  represents  the  external  environment. 


2.  I/O  Automata 

The  following  is  a  brief  introduction  to  a  model  which  is  described  in  [LM]  and  developed  at  length, 
with  “xtensions  to  express  infinite  behavior,  in  [LTj. 

All  components  in  our  systems,  transactions,  objects  and  schedulers,  will  be  modelled  by  //O  automata. 
An  I/O  automaton  A  has  a  set  of  states,  some  of  which  are  designated  as  tnitial  states.  It  has  operations, 
each  classified  as  either  an  input  operation  or  an  output  operation.  Finally,  it  has  a  transition  relation, 
which  is  a  set  of  triples  of  the  form  (s’,7r,s),  where  s’  and  s  are  states,  and  ir  is  .an  operation.  This  triple 
means  that  in  state  s’,  the  automaton  can  atomically  do  operation  n  and  change  to  stale  s.  An  element  of 
the  transition  relation  is  called  a  step  of  the  automaton.  The  output  operations  are  intended  to  model  the 
actions  that  are  triggered  by  the  automaton  itself,  while  the  input  operations  model  the  actions  that  are 
triggered  by  the  environment  of  the  automaton. 

Given  a  state  s’  and  an  operation  n,  we  say  that  w  is  enabled  in  s’  if  there  is  a  slate  s  for  which  (s'.ff.s)  is 
a  step.  We  require  the  following  condition. 

Input  Condition:  Each  input  operation  n  is  enabled  in  each  state  s'. 

This  condition  says  that  an  I/O  automaton  must  be  prepared  to  receive  any  input  operation  at  any  time 

An  execution  of  A  is  an  finite  alternating  sequence  s^.Trj,  Sj.-,,.  of  states  and  operation-  of 

beginning  and  ending  with  a  state.  Furthermore,  s^  is  a  .start  state  of  and  each  triple  (s'.r.s)  which 

occurs  as  a  consecutive  subsequence  is  a  step  of  A.  From  any  execution,  we  ran  extract  the  .-c/if du/r . 
which  is  the  subsequence  of  the  execution  consisting  of  operations  only.  Because  transitions  t,)  different 
states  may  have  the  same  operation,  different  executions  may  have  the  s.anie  schedule  We  s.iv  that  a* 
schedule  a  of  A  can  leaw  A  in  state  s  if  there  is  some  execution  of  J  with  schedule  o  and  fin  il  state  > 
We  s.ay  that  an  operation  i:  is  enabled  after  a  schedule  i.  of  •  if  tin  re  ex,>ts  a  stale  s  .-iich  that  o  c.in 
leave  A  in  state  s  and  n  is  enabled  in  s.  Since  the  same  operation  may  occur  several  times  in  an  execution 
or  schedule,  we  refer  to  a  single  occurrence  of  an  operation  as  an  event 
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We  describe  systems  as  consisting  of  interacting  components,  each  of  which  is  an  I/O  automaton.  It  is 
convenient  and  natural  to  view  systems  as  I/O  automata,  also  Thus,  we  define  a  composition  operation 
for  I/O  automata,  to  yield  a  new  I/O  automaton.  A  set  of  I/O  automata  may  be  composed  to  create  a 
system  S,  if  the  sets  of  output  operations  of  the  various  automata  are  pairwise  disjoint.  (Thus,  every 
output  operation  in  ,9  will  be  triggered  by  exactly  one  component.)  A  state  of  the  composed  automaton  is 
a  tuple  of  states,  one  for  each  component,  and  the  start  states  are  tuples  consisting  of  start  states  of  the 
components.  The  operations  of  the  composed  automaton  are  those  of  the  component  automata.  Thus, 
each  operation  of  the  composed  automaton  is  an  operation  of  a  subset  of  the  set  of  component  automata. 
An  operation  is  an  output  of  the  composed  automaton  exactly  if  it  is  an  output  of  some  component.  (The 
output  operations  of  a  system  are  intended  to  be  exactly  those  that  are  triggered  by  components  of  the 
system,  while  the  input  operations  of  a  system  are  those  that  are  triggered  by  the  system’s  environment.) 
During  an  operation  jt  of  a  composed  automaton,  each  of  the  components  which  has  operation  n  carries 
out  the  operation,  while  the  remainder  stay  in  the  same  state. 

An  execution  or  schedule  of  a  system  is  defined  to  be  an  execution  or  schedule  of  the  automaton 
composed  of  the  individual  automata  of  the  system.  If  or  is  a  schedule  of  a  system  with  component  A, 
then  we  denote  by  a\A  the  subsequence  of  a  containing  all  the  operations  of  A.  Clearly,  a\A  is  a  schedule 
of  A. 

The  following  lemma  from  [LMj  expresses  formally  the  idea  that  an  operation  is  under  the  control  of  the 
component  of  which  it  is  an  output. 

Lemma  1;  Let  a'  be  a  schedule  of  a  system  S,  and  let  a  =  a'n,  where  tt  is  an  output 
operation  of  component  A.  If  a|>l  is  a  schedule  of  A,  then  a  is  a  schedule  of  S. 

Proofs  Since  a\A  is  a  schedule  of  A,  there  is  an  execution  0  of  A  with  schedule  a\A.  Let  0' 
be  the  execution  of  A  consisting  of  all  but  the  last  step  of  0.  Similarly,  since  a'  is  a  schedule 
of  S,  there  is  an  execution  7  of  S  with  schedule  a’.  It  is  possible  that  A  has  an  execution  in  7 
which  is  different  from  0\  since  different  executions  may  have  the  same  schedule.  But  it  is 
easy  to  show,  by  induction  on  the  length  of  7,  that  there  is  another  execution  7’  of  S  in  which 
component  A  has  execution  0’,  and  which  is  otherwise  identical  to  7.  The  schedule  of  7’  is  a’. 
Since  n  is  not  an  output  operation  of  any  other  component,  n  is  defined  from  the  state  reached 
at  the  end  of  7’,  so  that  a  =  o’tt  is  a  schedule  of  S.  □ 

We  say  that  automaton  A  preserves  a  property  P  of  schedules  of  >1  if  a  =  o’tt  satisfies  P  whenever  a  is 
a  schedule  A,  a’  satisfies  P  and  tr  is  an  output  of  A. 

3.  Serial  Systems 

In  this  paper  we  define  two  kinds  of  systems:  "serial  systems"  and  "R/W  Locking  systems".  Serial 
systems  describe  serial  execution  of  transactions.  They  are  defined  for  the  purpose  of  giving  a  correctness 
condition  for  other  systems,  namely  that  the  schedules  of  another  system  should  look  like  schedules  of  the 
serial  system  to  the  transactions.  As  with  serial  executions  of  single-level  transaction  systems,  serial 


systems  are  too  inefficient  to  use  in  practice.  Thus,  we  will  define  R/W  Locking  .systems,  which  allow 
transactions  to  run  concurrently  or  abort  after  performing  some  work;  these  systems  use  Moss’  algorithm 
to  maintain  locks  uid  enough  information  to  restore  the  states  of  objects  after  aborts  occur. 


In  this  section  of  the  paper  we  define  serial  systems,  which  consist  of  transactions  and  basic  objects 
communicating  with  a  serial  scheduler.  Transactions  and  basic  objects  describe  user  programs  and  data, 
respectively.  The  serial  scheduler  controls  communication  between  the  other  components,  and  thereby 
controls  the  orders  in  which  the  transactions  create  children  or  access  data.  All  the  system  components 
are  modelled  as  I/O  automata.  Most  of  this  section  is  taken  from  [LMj.  with  slight  modifications  to 
accomodate  slight  changes  in  definitions. 


We  represent  the  pattern  of  transaction  nesting  by  a  systcin  type,  whicli  is  a  set  of  transaction  names. 
The  transaction  names  are  organized  into  a  tree  by  the  mapping  "parentO".  with  T^  as  the  root.  In 
referring  to  this  tree,  we  use  traditional  terminology',  such  as  child,  leaf,  least  common  ancestor  (Ica), 
ancestor  and  descendant.  (A  transaction  is  its  own  ancestor  and  descendant.)  The  leaves  of  this  tree  are 
called  accesses.  The  accesses  are  partitioned,  where  each  element  of  the  partition  contains  the  acces.ses  to 
a  particular  object.  The  partition,  including  the  names  of  the  objects,  is  part  of  the  system  type.  The 
tree  structure  can  be  thought  of  as  a  predefined  naming  scheme  for  all  possible  transactions  that  might 
ever  be  invoked  In  any  particular  execution,  however,  only  some  of  these  transactions  will  actually  take 
steps.  We  imagine  that  the  tree  structure  is  known  in  advance  by  all  components  of  a  system.  The  tree 
will,  in  general,  be  an  infinite  structure  with  infinite  branching. 


The  classical  transactions  of  concurrency  control  theory  (without  nesting)  appear  in  our  model  as  the 
children  of  a  ■mythical*  transaction,  T^j,  the  root  of  the  transaction  tree.  (In  work  on  nested 
transactions,  such  as  Argus,  the  children  of  T^^  arc  often  called  "top-level"  transactions.)  It  is  very 
convenient  to  introduce  the  new  root  transaction  to  inode!  the  environment  in  which  the  rest  of  the 
transaction  system  runs.  Transaction  T^j  has  operations  that  describe  the  invocation  and  return  of  the 


classical  transactions.  It  is  natural  to  reason  about  T^^  in  the  same  way  as  about  all  of  the  other 


transactions.  The  only  transactions  which  actually  acces.s  data  are  the  leav'-s  of  the  transaction  tree,  and 
thus  they  are  distinguished  as  "accesses".  The  internal  nodes  of  the  tree  model  transactions  whose 
function  is  to  create  and  manage  subtransactions,  but  not  to  access  data  directly. 


We  also  assume  that  a  system  type  includes  a  designated  set  V  of  to  be  used  as  return  valiie.s  of 

tran.sactions. 


A  serial  system  of  a  given  system  type  is  the  composition  of  a  set  of  I  O  automata.  This  set  contains  a 
transaction  automaton  for  each  internal  (i.e.  non-leaf,  non-access)  node  of  the  transaction  tree,  a  b.a.sic 
object  automaton  for  each  object,  and  a  serial  scheduler.  These  automata  are  described  below  . 
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3.1.  Transactions 

This  paper  differs  from  other  work  such  as  |BRG]  in  that  we  model  the  transactions  explicitly.  A  non- 
access  transaction  T  is  modelled  as  an  I/O  automaton,  with  the  following  operations. 

Input  operations: 

CREATE(T) 

REPORT_COMMIT(T’,v),  for  T’  a  child  of  T,  and  v  a  value 
REPORT_ABORT(T’),  for  T’  a  child  of  T 
Output  operations: 

REQUEST _CREATE(T’).  for  T’  a  child  of  T 

REQUEST  _COMMIT(T,v),  for  v  a  value 

The  CREIATE  input  operation  “wakes  up“  the  transaction.  The  REQUEST _ CREATE  output 
operation  is  a  request  by  T  to  create  a  particular  child  transaction.®  The  REPORT_COMMlT  input 
operation  reports  to  T  the  successful  completion  of  one  of  its  children,  and  returns  a  value  recording  the 
results  of  that  child’s  execution.  The  REPORT_ABORT  input  operation  reports  to  T  the  unsuccessful 
completion  of  one  of  its  children,  without  returning  any  other  information.  VVe  call 
REPORT_COMMIT(T’,v),  for  any  v,  and  REPORT_ABORT(T’)  report  operations  for  transaction  T’. 
The  REQUEST _ COMMIT  operation  is  an  announcement  by  T  that  it  has  finished  its  work,  and  includes 
a  value  recording  the  results  of  that  work. 

It  is  convenient  to  use  two  separate  operations,  REQUEST  _ CREATE  and  CREATE,  to  describe  what 
takes  place  when  a  subtransaction  is  activated.  The  REQUEST _  CREATE  is  an  operation  of  the 
transaction’s  parent,  while  the  actual  CREATE  takes  place  at  the  subtransaction  itself.  In  actual  systems 
such  as  Argus,  this  separation  does  occur,  and  the  distinction  will  be  important  in  our  results  and  proofs. 
Similarly,  we  distinguish  between  a  subtransaction’s  REQUEST _  COMMIT,  the  actual  COMMIT  (which 
is  internal  to  the  scheduler,  see  Section  3.3),  and  the  REPORT_ COMMIT  operation  of  the  parent 
transaction.^  We  leave  the  executions  of  particular  transaction  automata  largely  unspecified;  the  choice 
of  which  children  to  create,  and  what  value  to  return,  will  depend  on  the  particular  implementation.  For 
the  purposes  of  the  schedulers  studied  here,  the  transactions  (and  in  large  part,  the  objects)  are  “black 
boxes.  “  Nevertheless,  it  is  convenient  to  assume  that  schedules  of  transaction  automata  obey  certain 
syntactic  constraints.  We  therefore  require  that  all  transaction  automata  preserve  well-formedness,  as 


®Note  that  there  is  no  provision  for  T  to  pass  information  to  its  child  in  this  request.  In  a  programming  language,  T  might  be 
permitted  to  pass  parameter  values  to  a  subtransaction.  Although  this  may  be  a  convenient  descriptive  aid,  it  is  not  necessary  to 
include  it  in  the  underlying  formal  model.  Instead,  we  consider  transactions  that  have  different  input  parameters  to  be  different 
transactions. 

^Note  that  we  do  not  include  a  REQUEST  _ ABORT  operation  for  a  transaction:  we  do  not  model  the  situation  in  which  a 
transaction  decides  that  its  own  existence  is  a  mistake.  Rather,  we  a.ssign  decisions  to  abort  transactions  to  another  component  of 
the  system,  the  scheduler.  In  practice,  the  scheduler  must  have  some  power  to  decide  to  abort  transactions,  as  when  it  detects 
deadlocks  or  failures.  In  Argus,  transactions  are  permitted  to  request  to  abort;  we  regard  this  request  simply  as  a  'hint*  to  the 
scheduler,  to  restrict  its  allowable  executions  in  a  particular  way. 


defined  in  the  next  paragraph.  We  do  not  constrain  the  operation  of  a  transartioii  automaton  after 
schedules  that  violate  well-formedness,  but  we  will  prove  later  that,  when  placed  in  any  of  the  systems  we 
consider,  a  transaction  generates  only  well-formed  schedules. 

We  recursively  define  well-formedness  for  sequences  of  operations  of  transaction  T.  Namely,  the  empty 
schedule  is  well-formed.  Also,  if  a  =  o’ff  is  a  sequence  of  operations  of  T,  where  t  is  a  single  event,  then 
a  is  well-formed  provided  that  a'  is  well-formed,  and  the  following  hold. 

•  If  JT  is  CREATE(T),  then 

(i)  there  is  no  CREATE(T)  event  in  a’. 

•  If  ir  is  REPORT_COm«T(T’,v)  for  a  child  T’  of  T,  then 

(i)  REQUEST _CREATE(T’)  appears  in  o’  and 

(ii)  there  is  no  REPORT_ABORT(T’)  event  in  o’  and 

(iii)  there  is  no  REPORT_COMMIT(T’,v’)  event  with  v’^^v  in  o  '. 

•  If  IT  is  REPORT_ABORT(T’)  for  a  child  T’  of  T,  then 

(i)  REQUEST _CREATE(T’)  appears  in  o’  and 

(ii)  there  is  no  REPORT_COMMlT  event  for  T’  in  o’. 

•  If  jr  is  REQUEST_CREATE(T’)  for  a  child  T’  of  T,  then 

(i)  there  is  no  REQUEST _CREATE(T’)  event  in  o’  and 

(ii)  there  is  no  REQUEST _ COMMIT  event  for  T  in  o’  and 

(iii)  CREATE(T)  appears  in  o’. 

•  If  ir  is  REQUEST _COMMIT(T,v)  for  a  value  v,  then 

(i)  there  is  no  REQUEST _ COMMIT  event  for  T  in  o’  and 

(ii)  CREIATE(T)  appears  in  o’. 

These  restrictions  are  very  basic;  they  simply  say  that  a  transaction  does  not  get  created  more  than 
once,  does  not  receive  conflicting  information  about  the  fates  of  its  children,  and  does  not  receive 
information  about  the  fate  of  any  child  whose  creation  it  has  not  requested,  al.so.  a  transaction  does  not 
perform  any  output  operations  before  it  has  been  created  or  after  it  li.a.s  requested  to  commit,  and  does 
not  request  the  creation  of  the  same  child  more  than  onre.  Except  for  these  minimal  conditions,  there  are 
no  a  priori  restrictions  on  allowable  tran.saction  behavior 

The  following  easy  lemma  summarizes  the  projierties  of  well-formed  sequences  of  transaction  operations 
Lemma  2:  Let  o  be  a  well-formed  .sequence  of  operations  of  transaction  T  Then  the 
following  conditions  hold. 

1.  The  first  event  in  a  is  a  CREATIC(T)  event,  and  th  ere  are  no  other  ('RE  \TIC  events 

2.  If  a  REQUEST _ COMMIT  event  for  T  occurs  in  o.  thin  there  are  no  hater  output 
events  of  T  in  o. 

3.  There  is  at  most  one  REQrEST_CREATE(’l  )  eceut  for  eai  h  chlhi  T  of  T.  Ill  o. 

4.  There  are  not  two  different  report  operations  in  o  for  au\  child  T'  of  T  (However 
there  may  be  several  events  which  are  repeated  insianc--  of  .a  siugh-  report  operation) 

.5.  Any  report  event  for  a  child  T'  of  T  i-v  preceded  l.\  HliQI  liS  T  (  HI!  \'n'(  T  1  in  o 
C^onversely,  any  sequence  of  operations  of  T  satisfying  lhe>e  conditions  is  w ell- rornie.l 
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3.2.  Basic  Objects 

Recall  that  I/O  automata  are  associated  with  non-access  transactions  only.  Since  access  transactions 
model  abstract  operations  on  shared  data  objects,  we  associate  a  single  I/O  automaton  with  each  object, 
rather  than  one  for  each  access.  The  operations  for  each  object  are  just  the  CREATE  and 
REQUEST _  COMMIT  operations  for  all  the  corresponding  access  transactions.  Although  we  give  these 
operations  the  same  names  as  the  operations  of  non-access  transactions,  it  is  helpful  to  think  of  the 
operations  of  access  transactions  in  other  terms  also:  a  CREATE  corresponds  to  an  invocation  of  an 
operation  on  the  object,  while  a  REQUEST _ COMMIT  corresponds  to  a  response  by  the  object  to  an 
invocation.  Actually,  these  CREATE  and  REQUEST _ COMMIT  operations  generalize  the  usual 
invocations  and  responses  in  that  our  operations  carry  with  them  a  designation  of  the  position  of  the 
access  in  the  transaction  tree.  Thus,  a  baeic  object  X  is  modelled  as  an  automaton,  with  the  following 
operations. 

Input  operations: 

CRE)ATE(T),  for  T  an  access  to  X 
Output  operations: 

REQUEST _COMMIT(T,v),  for  T  an  access  to  X 

As  with  transactions,  while  specific  objects  are  left  largely  unspecified,  it  is  convenient  to  require  that 
schedules  of  basic  objects  satisfy  certain  syntactic  conditions.  We  recursively  define  well-formedness  for 
sequences  of  operations  of  basic  objects.  Namely,  the  empty  schedule  is  well-formed.  Also,  if  o  =  a'n  is 
a  sequence  of  operations  of  basic  object  X,  where  is  a  single  event,  then  a  is  well-formed  provided  that 
a'  is  well-formed,  and  the  following  hold. 

•  If  is  CREATE(T),  then 

(i)  there  is  no  CREATE(T)  event  in  o’. 

•  If  TT  is  REQUEST _COMMIT(T,v)  for  a  value  v,  then 

(i)  there  is  no  REQUEST _ COMMIT  event  for  T  in  o’,  and 

(ii)  CREATE(T)  appears  in  o’. 

These  restrictions  simply  say  that  the  same  access  does  not  get  created  more  than  once,  and  that  a  basic 
object  does  not  respond  more  than  once  to  any  access,  and  only  responds  to  accesses  that  have  previously 
been  created.  These  requirements  constrain  the  environment  of  the  object  slightly  less  than  those  in  [LM]; 
the  added  freedom  makes  .some  of  the  arguments  slightly  simpler.  We  require  that  every  basic  object 
preserve  well-formedness  (this  is  a  simple  syntactic  condition).  The  following  easy  lemma  summarizes  the 

properties  of  well-formed  sequences  of  basic  object  operations. 

Lemma  3:  Let  o  be  a  well-formed  sequence  of  operations  of  basic  object  X.  Then  for  any 

access  T  to  X,  a  contains  one  of  the  following 

(i)  no  CREATE(T)  and  no  REQUEST _COMMlT(T,v)  events,  or 

(ii)  one  CREATE(T)  and  no  REQtIEST_COMMIT(T,v)  events,  or 

(iii)  one  CREATE(T)  event  and  following  that  one  REQUEST _COMMlT(T,v)  event  for  some 


V. 
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Conversely,  any  or  satisfying  this  condition  is  well-formed. 

If  a  is  a  well-formed  sequence  of  operations  of  X  and  T  is  an  accps.s  lo  X  1,  that  o  contains 
CRE1A.TE(T)  but  no  REQUEST _ COMMIT(T,v),  we  say  that  T  is  pending  in  a. 

The  following  lemmas  explore  the  conditions  under  which  we  can  deduce  that  an  extension  of  a  well- 
formed  sequence  is  itself  well-formed. 

Lemma  4:  Suppose  a,  and  7  are  all  well-formed  sequences  of  operations  of  basic  object  X 
such  that  the  events  in  $  are  a  subset  of  the  events  in  m  (though  not  necessarily  in  the  same 
order)  and  the  events  in  7  are  a  subset  of  the  events  in  d  Let  ^  be  a  sequence  of  operations  of 
X  such  that  both  a<f>  and  7^  are  well-formed.  Then  /?<>  is  well-formed. 

Proof:  Since  $  is  well-formed  we  need  only  check  for  each  event  rr  in  o  the  presence  ami 
absence  of  certain  operations  preceding  n  in  Any  operation  whose  presence  is  needed  is 
present  in  7^  since  7^  is  well-formed,  and  hence  is  present  in  i3<i>.  while  similarly  any  operation 
whose  absence  is  required  is  absent  in  a<i>  and  thus  in  ^<j>.  □ 

Lemma  61  SuppKMe  a  and  0  are  well-formed  seqtiences  of  operations  of  basic  object  X  which 
contain  the  same  events  (perhaps  in  different  orders).  Let  ^  be  a  sequence  of  operations  of 
X.  Then  if  is  well-formed  so  is  $4>- 

Lemma  #1  Suppose  cr,  ^  and  7  are  sequences  of  operations  of  basic  object  X  such  that  a3  is 
well-formed,  and  the  set  of  accesses  whose  operations  occur  in  7  is  disjoint  from  the  set  of 
accesses  whose  operations  occur  in  0.  Then  0^7  is  well-formed  if  and  only  if  07  is  well-formed. 


3.S.  Serial  Scheduler 

The  third  kind  of  component  in  a  serial  system  is  the  serial  scheduler  The  serial  scheduler  is  also 
modelled  as  an  automaton.  Whereas  the  transactions  and  basic  objcct.s  have  been  specified  to  be  any  I  O 
automata  whose  operations  and  behavior  satisfy  simple  syntactic  restrictions,  the  serial  scheduler  is  a 
fully  specified  automaton,  particular  to  each  system  type.  It  runs  transactions  according  to  a  depth-first 
traversal  of  the  transaction  tree.  The  serial  scheduler  can  choose  nondeterininistically  to  abort  any 
transaction  after  its  parent  has  requested  its  creation,  as  long  as  the  transaction  ha.s  not  actualh'  been 
created.  In  the  context  of  this  scheduler,  the  "semantics*  of  an  ABORT(T)  operation  are  that 
transaction  T  was  never  created.  Each  child  of  T  whose  creation  was  reijuested  must  be  either  aborted  or 
run  to  commitment  with  no  siblings  overlapping  its  execution,  before  T  can  commit.  The  operations  of 
the  serial  scheduler  are  as  follows. 

Input  Operations: 

REQUEST  _  CREATE(T) 

REQUEST_COMMIT(T,v) 

Output  Operations: 

CREATE(T) 

COMMIT(T),  T  71^  Tg 

.\BORT(T),  T  7^  Tq 

REPORT _CO\fMlT(T,v),  T  T„ 

REPORT _ABORT(  r),  T  ^  Tj, 
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The  REQUEST _ CREATE  and  REQUEST  _  COMMIT  inputs  are  intended  to  be  identified  with  the 
corresponding  outputs  of  transaction  and  objert  automata,  and  forrespondingly  for  the  CREATE, 
REPORT _ COMMIT  and  REPORT _ ABORT  output  operations.  The  COMMIT  and  ABORT 
operations  are  internal,  marking  the  point  in  time  where  the  decision  on  the  fate  of  the  transaction  is 
irrevocable.  We  call  COMMIT(T)  and  ABORT(T)  rtturn  operations  for  T. 

Each  state  s  of  the  serial  scheduler  consists  of  six  sets,  named  with  record  notation;  s.create_requested, 
s. created,  s.commit_requested,  s. committed,  s. aborted  and  s. returned.  The  set  s.commit_requested  is  a 
set  of  (transaction, value)  pairs.  The  others  are  sets  of  transactions.  There  is  exactly  one  initial  state,  in 
which  the  set  create_ requested  is  {T^},  and  the  other  sets  are  empty. 

The  transition  relation  consists  of  exactly  those  triples  (s’,ff,s)  satisfying  the  pre-  and  postconditions 

below,  where  ir  is  the  indicated  operation.  For  brevity,  we  include  in  the  postconditions  only  those 

conditions  on  the  state  s  which  may  change  with  the  operation.  If  a  component  of  s  is  not  mentioned  in 

the  postcondition,  it  is  implicit  that  the  set  is  the  same  in  s’  and  s. 

REQUEST  _  CREATE(T) 

Postcondition; 

s.create_ requested  =  s’. create _ requested  U  {T} 

REQUEST  _  COMMIT{T.  v) 

Postcondition; 

s.commit_ requested  =  s’.commit_requested  U  {(T,v)} 

CREATE(T) 

Precondition: 

T  6  s’.create_ requested  -  (s’. created  U  s’. aborted) 
siblings(T)  n  s’. created  C  s’. returned 
Postcondition: 

s. created  =  s’. created  U  {T} 

COMMIT(T),  T  7^  Tq 
Precondition: 

(T,v)  6  s’.commit_  requested  for  some  v 
T  (2  s’. returned 

children(T)  fl  s’.create_ requested  C  s’. returned 
Postcondition: 

s. committed  =  s’. committed  U  {T} 
s. returned  =  s’. returned  U  (T) 

ABORT(T),  T  7^  Tp 

Precondition: 

T  €  s’.create_  requested  -  (s’. created  U  s’. aborted) 
siblings(T)  O  s’. created  C  s’. returned 
Postcondition: 

s. aborted  =  s’. aborted  U  (T) 
s. returned  =  s’. returned  U  {T} 
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REPORT  _ABORT(T),  T  ^  T,j 
Precondition: 

T  6  i’. aborted 

REPORT  _COMMIT(T,v),  T  ^  T^,  ' 

Precondition: 

T  €  s’.comnnitted 

(T,v)  €  s’.commit_requested 

The  input  operations,  REQUEST _ CREATE  and  REQUEST _ COMMIT,  simply  result  in  the  request 
being  recorded.  A  CREIATE  operation  can  only  occu:  if  a  corresponding  REQUE.ST_CRE.\TE  has 
occurred  and  the  CREATE  has  not  already  occurred.  The  second  precondition  on  the  CRE.\TE 
operation  says  that  the  serial  scheduler  does  not  create  a  transaction  until  all  its  previously  created  sibling 
transactions  have  returned.  That  is,  siblings  are  run  sequentially.  The  precondition  on  the  C0\1M1T 
operation  says  that  the  scheduler  does  not  allow  a  transaction  to  commit  until  its  children  have  returned. 
The  precondition  on  the  ABORT  operation  says  that  the  scheduler  does  not  abort  a  transaction  while  any 
of  its  siblings  are  active.  That  is,  aborted  transactions  are  dealt  with  sequentially  with  respect  to  their 
siblings.  The  result  of  a  transaction  can  be  reported  to  its  parent  at  any  time  after  the  (purely  internal) 
commit  or  abort  has  occurred.  In  particular,  siblings  might  run  in  one  order  and  be  reported  to  their 
parent  in  the  opposite  order. 

One  significant  difference  between  our  serial  scheduler  and  the  one  in  [LM’  i.s  that  there  the  return 
operation  and  the  report  to  the  parent  of  the  return  are  combined  as  a  single  operation,  giving  the  parent 
the  extra  information  of  the  order  in  which  its  children  are  run. 

The  next  lemma  relates  a  schedule  of  the  serial  scheduler  to  the  state  which  results  from  applying  that 
schedule. 

Lemma  7:  Let  a  be  a  schedule  of  the  serial  scheduler,  and  let  s  be  a  state  which  can  result 
from  applying  or  to  the  initial  state.  Then  the  following  conditions  are  true. 

1.  T  is  in  s.create_ requested  exactly  if  T  =  or  a  contains  a  REQLT-ST_CRE.ATE(T) 
event. 

2.  T  is  in  s. created  exactly  if  a  contains  a  CRF1\TE( T)  event. 

3.  {T,v)  is  in  s.commit_ requested  exactly  if  o  contains  a  REQUEST _COMMIT(T.v) 
event. 

4.  T  is  in  s. committed  exactly  if  a  contains  a  COVrMIT(T)  event. 

5.  T  is  in  s. aborted  exactly  if  a  contains  an  ABORT(T)  event. 

6.  s. returned  =  s. committed  U  s. aborted. 

7.  s. committed  (T  s. aborted  =  0. 


_ fill  a 


> 
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3.4.  Serial  Systems  and  Serial  Schedules 

The  composition  of  transactions  with  basic  objects  and  the  serial  scheduler  for  a  given  system  type  is 
called  a  serial  system,  and  its  operations  and  schedules  are  called  serial  operations  and  serial  schedules, 
respectively.  We  note  that  every  serial  operation  is  an  operation  of  the  serial  scheduler,  and  of  at  most 
one  other  component  of  the  serial  system.  A  sequence  a  of  serial  operations  is  said  to  be  well-formed 
provided  that  its  projection  at  every  transaction  and  basic  object  is  well-formed. 

Lemma  8:  Let  a  be  a  serial  schedule.  Then  a  is  well-formed. 

Proof:  By  induction  on  the  length  of  schedules.  The  base,  length  =  0,  is  trivial.  Suppose 
that  an  is  a  serial  schedule,  and  assume  that  a  is  well-formed.  If  n  is  an  output  of  a  basic 
object  or  non-access  transaction  P,  then  crn'lP  is  well-formed  because  P  preserves  well- 
formedness,  and  so  an  is  well-formed.  So  assume  that  n  is  an  input  to  a  basic  object  or  non- 
access  transaction  P.  It  suffices  to  show  that  offlP  is  well-formed.  There  are  three  cases. 

(1)  n  is  CREATE(T)  for  some  transaction  T. 

The  scheduler  preconditions  and  Lemma  7  ensure  that  CREATE(T)  does  not  appear  in  a. 

(2)  n  is  REPORT _COMMIT(T,v)  for  some  transaction  T  and  value  v. 

Then  n  is  an  input  to  transaction  parent(T)  —  T’.  The  scheduler  preconditions  and  Lemma  7 
imply  that  a  contains  REQUEST _COMMIT(T,v).  Well-formedness  of  a  at  the  non-access 
transaction  T  (or  at  basic  object  X,  if  T  is  an  access  to  X)  implies  that  a  contains 
CREATE(T),  and  the  scheduler  preconditions  and  Lemma  7  then  require  that  a  contains 
REQUEST  _CREATE(T).  Also,  scheduler  preconditions  and  Lemma  7  imply  that 
COMMIT(T)  occurs  in  a,  and  thus  no  ABORT(T)  occurs  in  a.  Thus  no 
REPORT _ABORT(T)  occurs  in  a,  by  the  scheduler  preconditions.  Well-formedness  at  T  (or 
at  X,  if  T  is  an  access  to  X)  implies  that  no  REQUEST_COMMlT(T,v’)  with  v’  ^  v,  occurs 
in  a,  and  therefore  by  the  scheduler  preconditions,  no  REPORT_COMMIT(T,v’),  v  ^  v 
occurs  in  a. 

(3)  n  is  REPORT _ABORT(T)  for  some  transaction  T. 

Then  n*  is  an  input  to  transaction  parent(T)  =  T’.  The  scheduler  preconditions  and  Lemma  7 
imply  that  a  contains  ABORT(T)  and  hence  contains  REQU’EST_CREATE(T)  but  no 
CREATE(T).  The  analysis  above  shows  that  this  is  incompatible  with  the  presence  of  any 
REPORT _ COMMIT  event  for  T.  □ 

If  O!  is  a  sequence  of  serial  operations  and  T  is  a  transaction  such  that  a  contains  CREATE(T)  but  no 

return  event  for  T,  we  say  that  T  is  live  in  a.  The  following  are  useful  observations: 

Lemma  0:  Let  a  be  a  serial  schedule,  T  a  transaction  live  in  a  and  T’  an  ancestor  of 
T.  Then  T’  is  live  in  a. 

Lemma  10:  Let  a  be  a  serial  schedule,  and  T  and  T’  distinct  sibling  transactions.  If  T  is 
live  in  a,  then  T’  is  not  live  in  a. 

A  consequence  of  the  two  previous  lemmas  is  the  following,  which  states  that  only  related  transactions 
can  be  live  concurrently,  in  a  serial  schedule. 

Lemma  11:  Let  a  be  a  serial  schedule,  and  T  and  T’  transactions  each  of  which  is  live  in  a. 
Then  either  T  is  an  ancestor  of  T’  or  T’  is  an  ancestor  of  T. 


In  order  to  talk  about  schedules,  we  introduce  some  terms  to  describe  the  fate  of  transactions.  Let  o  be 
any  sequence  of  operations.  (We  will  use  these  same  terms  later  for  schedules  of  R  VV  Locking  systems,  so 
we  make  the  definitions  for  general  sequences.)  If  T  a  transaction  and  T’  an  ancestor  of  T,  we  say  that 
T  is  committed  to  T’  in  o  if  COMMIT(U)  occurs  in  a  for  every  U  which  is  an  ancestor  of  T  and  a  proper 
descendant  of  T’.  If  T  and  T’  are  transactions  we  say  that  T  is  visible  to  T’  in  o  if  T  is  committed  to 
lca(T,T’).  If  w  is  one  of  the  operations  CREATE{T),  REQUEST_CREATE(T’),  COMMIT(T’), 
ABORT(T’),  REPORT _COMMIT(T’,v’),  REPORT _ABORT(T’.v’)  or  REQLT:ST_COMMIT(T,v) 
where  T’  is  a  child  of  T,  then  we  define  transact ion(w)  to  be  T.  If  T  is  a  non-access  transaction  then  the 
operations  tr  with  transaction(ff)  =  T  are  the  operations  of  the  automaton  T  together  with  the  return 
operations  for  children  of  T.  We  denote  by  visible(o,T)  the  subsequence  of  n  consisting  of  events  tt  with 
transaction(»r)  visible  to  T  in  a.  Notice  that  every  operation  occurring  in  visible(o,Tj  is  a  serial  operation. 

VV  e  collect  here  some  straightforward  consequences  of  these  definitions. 

Lemma  12t  Let  a  be  a  sequence  of  operations,  and  T,  T’  and  T”  transactions. 

1.  If  T  is  an  ancestor  of  T’,  then  T  is  visible  to  T’  in  Of. 

2.  T’  is  visible  to  T  in  cf  if  and  only  if  T’  is  visible  to  lca(T,T’)  in  o. 

3.  If  T”  is  visible  to  T’  in  o  and  T’  is  visible  to  T  in  a,  then  T"  is  visible  to  T  in  a. 

4.  If  T’  is  a  proper  descendant  of  T,  T”  is  visible  to  T’  in  a,  but  T"  is  not  visible  to  T  in 
Q,  then  T”  is  a  descendant  of  the  child  of  T  which  is  an  ancestor  of  T’. 

Lemma  13:  Let  a  and  be  sequences  of  operations,  such  that  p  consists  of  a  subset  of  the 
events  of  o. 

1.  If  transaction  T  is  visible  to  transaction  T’  in  then  T  is  visible  to  T’  in  a. 

2.  If  event  tr  is  in  visible(/9,T),  then  ir  is  in  visibk(Q,T). 

Lemma  14:  Let  a  be  a  sequence  of  operations,  and  let  T  and  T’  be  transactions.  Then 
visible(a,T)|T’  is  equal  to  o|T’  if  T’  is  visible  to  T  in  o,  and  is  equal  to  the  empty  sequence 
otherwise. 

Lemma  15:  Let  a  be  a  sequence  of  operations.  Let  T.  T’  and  T”  be  transactions  such  that 
T”  is  visible  to  T’  and  to  T  in  a.  Then  T”  is  visible  to  T'  in  visiblt(a,T) 

Lemma  16:  Let  T  be  a  transaction,  and  let  be  a  .sequence  of  operations,  where  tt  is  a 
single  event. 

1.  If  transaction(n-)  is  not  visible  to  T  in  on,  then  visible(o7r,T)  ==  visible(o .T). 

2.  If  transaction{rr)  is  visible  to  T  in  an  and  if  n  is  not  a  COMMIT  event,  then 
visible(oa-,T)  =  visible(o,T)Tr. 

3.  If  transaction(7r)  is  visible  to  T  in  an.  and  n  is  C()M.M1T(1’)  then  the  events  in 
visible(a7r,T)  are  those  visible  in  a  to  either  T  or  C,  together  with  n  itself. 

Lemma  17:  Let  q  be  a  well-formed  sequence,  and  T  any  transaction  Then  \  isiblelo  .T)  is 
well-formed. 


The  next  two  lemmas  are  taken  from  'LM,.  (There,  they  are  proved  with  sliglitly  different  d.  finition' 
but  essentially  the  same  proofs  work  here.) 

Lemma  18:  Let  o  be  a  serial  schedule  and  T  a  transaction.  Then  visiblefc^ .T)  i'  a  -.erial 
schedule. 

Lemma  Ifl:  Let  a  be  a  serial  schedule  and  T  a  transaction.  Let  f  -  visible(  o.T)  Tlnn 
—  ff{a  -  /9)  is  a  serial  schedule. 
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Let  a  be  any  sequence  of  operations.  If  T  is  a  transaction  we  say  T  is  an  orphan  in  a  if  ABORT(U) 
occurs  in  o  for  some  ancestor  U  of  T.  The  following  lemmas  are  straightforward. 

Lemma  20:  Let  a  and  0  be  sequences  of  operations  such  that  0  consists  of  a  subset  of  the 
events  in  a.  If  a  transaction  T  is  not  an  orphan  in  o  then  T  is  not  an  orphan  in  0. 

Lemma  21:  Let  a  is  a  sequence  of  operations.  If  T  is  a  transaction  that  is  not  an  orphan  in 
a  and  T’  is  an  ancestor  of  T,  then  T’  is  not  an  orphan  in  q. 

3.5.  Serial  Correctness 

We  use  serial  schedules  as  the  basis  of  our  correctness  definition,  which  was  first  given  in  [LM’. 
Namely,  we  say  that  a  sequence  of  operations  is  serially  correct  for  a  transaction  T  provided  that  its 
projection  on  T  is  identical  to  the  projection  on  T  of  some  serial  schedule.  That  is,  the  sequence  "looks 
like"  a  serial  schedule  to  T.  Later  in  this  paper  we  will  define  "R/W  Locking  systems"  and  show  that 
their  schedules  are  serially  correct  for  every  non-orphan  transaction,  and  in  particular  that  these  schedules 
are  serially  correct  for  the  root  transaction  T^. 

Motivation  for  our  use  of  serial  schedules  to  define  correctness  derives  from  the  simple  behavior  of  the 
serial  scheduler,  which  determines  the  sequence  of  interactions  between  the  transactions  and  objects.  W'e 
believe  the  depth-first  traversal  of  the  transaction  tree  to  be  a  natural  notion  of  correctness  which 
corresponds  precisely  to  the  intuition  of  how  nested  transaction  systems  ought  to  behave.  Furthermore,  it 
is  a  natural  generalization  of  serializability,  the  correctness  condition  generally  chosen  for  classical 
transaction  systems.  Serial  correctness  for  T  is  a  condition  which  guarantees  to  implementors  of  T  that 
their  code  will  encounter  only  situations  which  can  arise  in  serial  executions.  Correctness  for  T^  is  a 
special  case  which  guarantees  that  the  external  world  will  encounter  only  situations  which  can  arise  in 
serial  executions. 

It  would  be  best  if  every  transaction  (whether  an  orphan  or  not)  saw  data  consistent  with  a  serial 
execution.  Ensuring  this  requires  a  much  more  intricate  scheduler  than  the  simple  R/W  Locking  systems 
we  describe.  In  [IILMW],  we  describe  and  prove  correctness  of  several  algorithms  for  mainintaining 
correctness  for  orphan  transactions. 

Our  approach  is  an  example  of  a  general  technique  for  studying  system  algorithms.  A  simple,  intuitive 
and  inefficient  algorithm  (automaton)  is  used  to  specify  an  acceptable  collection  of  schedules  for  the 
system  component.  The  actual  system  component  is  more  efficient  or  robust,  but  provides  the  same  user 
interface.  The  user  is  guaranteed  that  applications  (transactions,  in  our  work)  which  work  well  when  run 
with  the  simple  algorithm  will  work  the  same  way  when  run  with  the  actual  system. 
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4.  Semantic  Conditions 

la  the  serial  systems  to  be  considered  in  this  paper,  accesses  are  classified  as  eifher  read  or  write 
accesses.  In  this  section,  we  state  the  properties  which  these  accesses  are  required  to  satisfy.  First,  we 
define  the  fundamental  concept  of  "equieffectiveness*  of  schedule*  which  is  in  turn  used  to  define 
“transparency*  of  operations;  an  operation  is  said  to  be  transparent  if  later  accesses  to  the  same  object 
return  values  which  are  the  same  as  in  the  situation  where  the  operation  did  not  occur.  We  then  prove 
certain  consequences  of  these  definitions,  which  will  be  used  in  tin  ensuing  proof*.  Finally,  we  use  the 
notion  of  transparency  to  specify  the  precise  semantic  conditions  which  read  and  write  accesses  must 
satisfy. 

4.1.  EquieiTective  Schedules 

We  introduce  the  concept  of  equieffective  .schedules  of  a  basic  object  X'.  in  order  to  define  precisely  what 
schedules  we  will  regard  as  “essentially*  the  same.  Intuitively,  these  are  schedules  which  leave  the 
automaton  in  states  which  are  the  same.  However,  we  are  really  interested  in  observable  behavior,  not 
states,  so  it  is  enough  that  they  be  indistinguishable  by  later  operations.  Formally,  given  two  well-formed 
sequences  a  and  $  of  operations  of  X,  we  say  that  q  is  equieffective  to  3  if  for  every  sequence  0  of 
operations  of  X  such  that  both  aip  and  3<t>  are  well-formed,  (\4>  is  a  schedule  of  X  if  and  only  if  06  is  a 
schedule  of  X.  Notice  that  if  neither  a  nor  ^  is  a  schedule  of  X,  then  a  is  trivially  equieffective  to  5. 
,\lso,  notice  that  if  a  is  equieffective  to  0  and  0  \s  &  schedule  of  X,  then  o  is  a  schedule  of  X.  In  the  sense 
of  semantic  theory,  equieffective  schedules  pas.s  the  same  tests,  where  a  test  involves  determining  if  a 
given  sequence  of  operations  can  occur  after  the  sequence  being  tested.  We  limit  the  tests  to  sequences 
which  do  not  violate  well-formedness,  for  technical  reasons,  because  we  have  not  required  the  objects  to 
behave  sensibly  if  the  inputs  violate  well-formedness.  Clearly,  o  is  equieffective  to  0  if  and  only  if  0  is 
equieffective  to  a  and  in  this  case  we  say  that  a  and  0  are  equieffective  sequences.  We  have  a  restricted 
form  of  transitivity: 

Lemma  22:  Let  q,  0  and  q  be  well-formed  sequences  of  operations  of  X  such  that  the  events 
in  0  are  a  subset  of  the  events  in  a  and  the  events  in  i  are  a  subset  of  the  events  in  0  (perhaps 
in  different  orders).  If  a  and  0  are  equieffective  and  also  3  and  ~t  are  equieffective,  then  o  and 
-y  are  equieffective. 

Proof;  Straightforward,  using  Lemma  4.  □ 

We  also  have  two  extension  results. 

Lemma  23:  If  q  and  3  are  equieffective  well-forined  .sequences  of  operations  of  X,  :ind  o  is  a 
sequence  of  operations  of  X  such  that  ntt>  and  d<s  are  well-formed,  then  oO  and  3o  are 
equieffective. 

Proof:  This  is  immediate,  since  well-formed  e.\ieii*ions  oi  no  are  well-formed  "xiensioiis  of 
O'.  □ 

Lemma  24:  If  a  and  0  are  equieffective  well-formed  sequemes  of  operations  of  X  that 
contain  the  same  events,  and  d>  is  a  sequence  of  operations  of  X  '•u'-h  that  oo  is  a  we  11-formed 
schedule  of  X,  then  0<p  is  a  well-formed  schedule  of  X  that  is  ecjuieffe.  i i\ e  to  oo 


Proof;  Straightforward,  by  Lemma  5  and  Lemma  23,  and  the  definition  of  equieffective.  □ 

We  say  that  an  operation  n  of  basic  object  X  is  traneparent  if  for  any  well-formed  schedule  air  of  X,  air 
is  equieffective  to  a.  Thus,  later  operations  that  do  not  violate  well-formedness  cannot  detect  whether  ir 
happened.  (Notice  that  we  only  require  ir  to  be  undetectable  in  situations  where  it  can  occur,  i.e.  when 
air  is  a  well-formed  schedule.) 

The  following  consequences  of  the  definitions  above  show  that  certain  rearrangements  of  an  object’s 
schedules  are  themselves  schedules,  and  are  "observably"  the  same. 

Lemma  25:  Let  afi  be  a  well-formed  schedule  of  basic  object  X,  where  every  operation  in  /3 
is  transparent.  Let  qf  be  a  sequence  of  operations  of  X  such  that  the  set  of  accesses  with 
operations  in  ')  is  disjoint  from  the  set  of  accesses  with  operations  in  and  such  that  a0~t  is 
well-formed.  Then  0:7  and  a0'i  are  equieffective,  and  also  07  is  a  schedule  of  X  if  and  only  if 
aff'l  is  a  schedule  of  X. 

Proof:  We  use  induction  on  the  length  of  0.  The  base  case  where  0  is  empty  is  trivial. 
Suppose  then  that  0  has  length  k  and  that  the  lemma  is  true  for  all  shorter  0.  Write  0=0’ir, 
where  0'  has  length  k-1.  Now,  jr  is  transparent  so  a0=  a0’ir  is  equieffective  to  a0'  (since  at  0'ir 
is  a  schedule  of  X).  Since  a0’ir'f  is  well-formed  and  no  operations  occurring  in  7  involve  the 
access  of  which  ir  is  an  operation,  we  have  that  a0'‘y  is  well-formed  by  Lemma  6.  By  Lemma 
23,  a/9’7  is  equieffective  to  a0'i.  Also,  the  definition  of  equieffective  allows  us  to  conclude  that 
a0'y  is  a  schedule  of  X  if  and  only  if  a/9’7  is  a  schedule.  The  induction  hypothesis  says  that  07 
is  equieffective  to  a/9’7,  and  that  a/9’7  is  a  schedule  of  X  if  and  only  if  07  is  a  schedule.  Thus 
a7  is  a  schedule  if  and  only  if  a/97  is,  and  Lemma  22  implies  that  they  are  equieffective.  □ 

Lemma  20:  Let  a  be  a  well-formed  schedule  of  basic  object  X,  and  S  a  set  of  accesses  to  X 
such  that  any  operation  of  a  transaction  in  S  that  occurs  in  a  is  transparent.  Let  0  be  the 
subsequence  of  a  obtained  by  removing  all  the  operations  of  accesses  in  S.  Then  0  is  &  well- 
formed  schedule  of  X  that  is  equieffective  to  a. 

Proof:  Repeatedly  apply  Lemma  25.0 

4.2.  Reordering  and  Combining  Serial  Schedules 

In  this  subsection,  we  describe  ways  in  which  serial  schedules  can  be  modified  and  combined  to  yield 
other  serial  schedules.  These  lemmas  are  used  in  the  proof  of  Lemma  48,  in  Section  6.3.  The  first 
generalizes  a  lemma  in  [LM],  taking  into  account  the  special  properties  of  transparent  operations.  The 

second  is  essentially  the  same  as  a  lemma  of  [LM].  The  proofs  are  straightforward. 

Lemma  27:  Let  a/9jC0MMIT(T’)  and  a0^  be  two  serial  schedules  and  T,  T’  and  T”  three 
transactions  such  that  the  following  conditions  hold: 

1.  T’  is  a  child  of  T”  and  T  is  a  descendant  of  T”  but  not  of  T’, 

2.  a/9j  =  visible(a/9j,T’), 

3.  a0^  =  visible(a;92,T), 

4.  a  =  visible(a/9j,T”)  =  visible(a/92,T”)  and 

5.  if  any  basic  object  has  an  output  operation  in  0^  then  all  its  operations  in  0^  are 
transparent. 

Then  a/9jCOMMIT(T’),92  is  a  serial  schedule. 

Proof:  Note  first  that  if  T  =  T”,  then  0^  is  empty  and  the  result  is  trivial.  So  assume  that 
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T  T”.  Then  T  is  a  descendant  of  a  child  U  of  T”,  and  U  ^  T’. 

Any  event  jt  in  for  which  transaction{ff)  is  not  a  descendant  of  T',  must  be  in 

visible{o)Sj,T”)  by  Lemma  12.  Similarly,  any  event  in  having  transaction  which  is  not  a 
descendant  of  U,  must  be  in  visible(Q^2,T”).  Thus,  0^  and  0^  contain  only  operations  having 
transactions  which  are  descendants  of  T’  and  U,  respectively.  Since  T’  and  U  are  distinct 
siblings,  and  any  operation  of  a  transaction  P  has  transaction  equal  to  P,  it  follows  that  no 
transaction  has  operations  occurring  in  both  0^  and  0^. 

We  proceed  by  induction  on  prefixes  of  a/3jCOMMIT(T’),J„.  Let  a’0  be  a  prefix  of 
a^jCOMMIT(T’)/92,  with  a’  a  serial  schedule  and  <t>  an  event  We  use  (>:^ijCO\'rMIT(T’)  as  the 
basis,  since  a/9jCOMMIT(T’)  is  a  serial  schedule  by  assumption.  So  assume  that  a’  = 
a/JjCOMMlT(T’)/9’  for  some  prefix  0'  of  0^.  There  are  three  cases,  depending  on  whether  (}>  is 
an  output  of  a  basic  object,  of  a  non-access  transaction,  or  of  the  serial  scheduler. 

Suppose  that  ^  is  an  output  of  a  basic  object  X.  By  assumption,  every  operation  of  /JJX  is 
transparent,  and  since  COMMIT(T’)  does  not  occur  at  X.  so  is  every  operation  of 
/9jCOMMIT(T’)|X.  We  saw  above  that  the  set  of  accesses  with  operations  in  and  the  set  of 
accesses  with  operations  in  0^  are  disjoint  (being  respectively  descendants  of  T’  and  of  L  ).  By 
Lemma  6,  a^jCOMMIT(T’)/3’^|X  is  well-formed,  and  we  may  deduce  by  Lemma  2.5  that 
ay9jCOMMIT(T’)^’^|X  is  a  schedule  of  X,  since  q0'((>\K  is  a  schedule.  Now  the  result  follows 
by  Lemma  1. 

Suppose  that  <t>  is  an  output  operation  of  a  non-access  transaction  P.  Then  ,'?jCONfMlT(T') 
contains  no  operations  of  P.  Thus,  q’<^1P  =  a^’<^jP,  which  is  a  prefix  of  ai3.,|P.  which  is  a 
schedule  of  P  since  a0^  is  a  serial  schedule.  Thus,  q’i^|P  is  a  schedule  of  P.  The  result  follows 
by  Lemma  1. 

Finally,  suppose  ^  is  an  output  of  the  serial  scheduler.  Then  6  has  transaction  for  some 
descendant  V  of  U.  Let  s  be  the  (uniquely  defined)  state  of  the  serial  scheduler  after  o',  and  let 
s’  be  the  state  of  the  serial  scheduler  after  n3'  Then  the  following  relation.'^hips  hold  between 
s  and  s’. 

1.  V  6  s’.create_ requested  -  (s’. created  U  s’. aborted)  iff  V  0  s.create_ requested  - 
(s. created  U  s. aborted) 

2.  children(V)  n  s’.create_ requested  C  s’. returned  iff  children(\  )  n  s,cre.ite_ requested  C 
s. returned 

3.  (V,v)  €  s’.commit_requested  iff  (V,v)  €  s  commit _ requested 

4.  V  €  s’.commitcd  iff  V  €  s  commited. 

5.  V  e  s’. aborted  iff  V  €  s. aborted 

8.  V  f?  s’. returned  iff  V  ^  s. returned 

7.  siblings(V)  fl  s’. created  C  s’. returned  iff  siblings(\')  n  s. created  C  s. returned 
Since  any  event  in  0^  has  transaction  equal  to  some  descendant  of  7’’,  and  the  operations 
REQirEST_CREATE(V),  CREATE(V).  .\Bt)irr(V),  HEQl'EST_COMMlT(V,v), 
COMMIT(V),  and  REQUEST_  CREATE(V),  AB()RT(\  '),  COMMlT(\-)  for  \  '  a  child  of  \'. 
all  have  transaction  equal  to  V  or  parent(V),  neither  of  which  is  a  descendant  of  T‘,  the  first 
six  biconditionals  are  immediate  from  Lemma  7.  If  \'  is  a  proper  descendant  of  I',  the  la.^t 
biconditional  also  follows.  It  remains  to  show  that  siblings(l')  n  s'  created  C  s'. returned  iff 
siblings{U)  O  s. created  C  s.rtlurned  But  any  sil  ling  of  E  creatid  in  o  L  is  irtatvJ  in  o'  and 


19 


i 


P 

V 


5 

■? 


the  only  sibling  of  U  created  in  a’  and  not  a/3’  is  T’,  and  T’  6  s. returned.  Thus,  the  claims 
are  true. 

Since  <f>  is  enabled  in  s’,  the  claims  above  imply  that  (j>  is  also  enabled  in  s.  The  result 
follows  by  Lemma  1.  □ 

Lemma  28:  Let  qABORT(T’)  and  aff  be  two  serial  schedules,  and  let  T,  T’  and  T"  be 
transactions,  such  that  the  following  conditions  hold: 

1.  T’  is  a  child  of  T”  and  T  is  a  descendant  of  T”  but  not  of  T’, 

2.  a0  =  visible(Q(/9,T),  and 

3.  a  =  visible(a,T”)  =  visible(od,T”). 

Then  aABORT(T’)/3  is  a  serial  schedule. 

4.3.  Semantiea  of  Read  Aeeesaes 

Finally,  we  are  ready  to  state  the  conditions  to  be  satisfied  by  read  and  write  accesses.  Namely,  we 
require  that  each  basic  object  X  satisfy  the  following  conditions. 

Semantic  Conditions: 

(i)  Every  CREATE(T)  operation  is  transparent. 

(ii)  For  any  and  a^  for  which  0'jCREATE(T)ar2  aja2CREATE(T)  are  both  well-formed  schedules 
of  X,  they  are  equieffective  schedules. 

(iii)  Every  REQUEST _COMMIT(T,v)  operation,  for  T  a  read  access,  is  transparent. 

Condition  (i)  means  that  whether  or  not  an  access  was  created  is  invisible  to  other  accesses.  Condition 
(ii)  means  that  later  operations  cannot  detect  when  an  access  was  created.  Condition  (iii)  means  that 
later  operations  cannot  determine  whether  or  not  a  REQUEST  _  COMMIT  operation  for  a  read  access  has 
occurred.  The  third  condition  captures  the  fundamental  feature  of  read  accesses  that  allows  Moss’ 
algorithm,  as  given  in  the  construction  of  R/W  Locking  objects  in  Section  5.1,  to  work.  In  contrast,  the 
first  two  conditions  are  a  convenience,  used  to  avoid  explicitly  reordering  schedules  of  the  R/W  locking 
objects.  Note  that  we  make  no  assumption  about  the  semantics  of  REQUEST _  COMMIT  operations  for 
write  accesses,  and  so  it  is  legitimate  to  designate  all  accesses  as  writes.  If  this  is  done.  Moss’  algorithm 
as  given  in  this  paper  degenerates  into  exclusive  locking. 

An  example  of  a  basic  object  satisfying  these  conditions  would  have  as  its  state  a  set  of  transactions, 
called  "pending",  and  an  instance  of  an  abstract  data  type.  The  input  operation  CREATE(T)  would 
simply  add  T  to  pending.  At  any  time,  a  transaction  T  in  pending  could  be  chosen,  and  the 
corresponding  function  applied  to  the  instance  of  the  abstract  data  type,  yielding  return  value  v,  and  a 
possibly  altered  instance  of  the  abstract  type.  T  would  be  removed  from  pending,  the  new  instance  would 
replace  the  old  one  in  the  state  of  the  basic  object,  and  REQUEST _COMMIT(T,v)  would  occur.  (The 
whole  sequence  from  choosing  T  to  the  output  is  an  atomic  step  of  the  basic  object.) 
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The  following  lemma  combines  all  the  information  in  the  semantic  conditions  to  give  a  simple  sufficieiit 
condition  for  proving  that  schedules  are  equieffective.  This  test  is  used  throughout  this  pa[)er  Cdvcn  a 
sequence  q  of  operations  of  X,  define  write(a)  to  be  the  subsequence  of  a  consisting  of  the 
REQUEST _COMMIT(T,v)  events  for  write  accesses  T.  If  q  and  l3  are  sequences  of  operations  of  X  and 
write{a)  =  write(;9)  then  we  say  that  a  and  are  write-equal.  This  is  clearly  an  equivalence  relation  on 
sequences  of  operations  of  X. 

Lemma  29:  Let  a  and  be  well-formed  schedules  of  X  that  are  write-equal.  Then  o  and  ^ 
are  equieffective. 

Proof:  Suppose  ^  is  a  sequence  of  operations  of  X  such  that  and  34>  are  both  well- 

formed.  We  must  prove  that  l3<t>  is  a  schedule  of  X  if  and  only  if  q<>  is  a  schedule  of 
X.  Consider  the  set  A  of  accesses  to  X  that  is  the  union  of  the  set  of  write  accesses  for  which  a 
REQUEST _ COMMIT  operation  occurs  in  a  (and  so  also  in  3)  and  the  set  of  accesses  that  art- 
pending  in  both  Q  and  0.  Let  a’  denote  the  subsequence  of  a  consisting  of  the  events  of 
accesses  in  A.  Similarly  let  0'  denote  the  subsequence  of  0  consisting  of  the  events  of  accesses 
in  A.  Since  a'  is  obtained  from  a  by  removing  all  the  operations  of  accesses  not  in  A,  and  all 
such  operations  are  transparent  (by  conditions  (i)  and  (iii)),  by  Lemma  26,  we  deduce  that  a'  is 
a  well-formed  schedule  of  X  equieffective  to  a.  Similarly  0’  is  a  well-formed  schedule 
equieffective  to  0.  Also,  since  a’  can  be  formed  from  0'  by  moving  CREATE  events,  we  deduce 
from  condition  (ii).  Lemma  24  and  Lemma  22  that  q’  and  0'  are  equieffective.  Since  both  qc> 
and  04>  are  well-formed,  by  Lemma  3  any  event  in  <i)  must  be  either  an  operation  of  an  access 
with  no  operations  in  a  or  0,  or  else  a  REQUEST _ COMMIT  for  an  access  that  is  pending  in 
both  a  and  0.  In  any  case,  a’4>  and  /dV  must  be  well-formed.  Therefore  n(^  is  a  schedule  of  X 
if  and  only  if  a’<i>  is  a  schedule,  which  is  true  if  and  only  if  0'<i)  is  a  schedule  and  so  if  and  only 
if  04>  is  a  schedule  of  X.  □ 

5.  R/W  Locking  Systems 

A  R/W  Locking  system  of  a  given  system  type  is  composed  of  transactions,  a  generic  scheduler,  and 
R/W  Locking  objects.  The  non-access  transactions  are  modelled  by  the  same  automata  as  in  the  serial 
system,  but  the  generic  scheduler  has  much  more  freedom  in  scheduling  transactions  than  the  serial 
scheduler,  and  R/W  Locking  objects  follow  the  algorithm  of  (Mo’  in  maintaining  locking  and  state 
restoration  data  that  basic  objects  do  not  need. 

5.1.  R/W  Locking  objects 

In  this  section,  we  define,  for  each  basic  object  X,  a  R/W  Locking  object  M(X),  which  provides  a 
resilient  lock-managing  variant  of  X.  It  receives  operation  invocations  and  responds  like  X.  and  also 
receives  information  about  the  fate  of  transactions  so  that  it  can  maintain  its  locking  and  state 
restoration  data.  A  R/W  Locking  object  combines  the  features  of  the  resilient  object  and  the  lock 
manager  of  [LM],  where,  as  in  many  database  management  systems,  the  recovery  and  concurrency  control 
are  performed  separately.  Combining  these  features.  a.s  we  do  here,  eliminate^  some  redundatiey  in 
maintaining  information  about  the  fate  of  transactions. 


V1(X)  has  the  following  operations. 
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Input  Operations; 

CREATE(T),  for  T  an  access  to  X 
lNFORM_COMMIT_AT{X)OI'(Tj,  T 
INFORM _ ABORT  _AT(X)OF(T),  T  ^  T^ 

Output  Operations: 

REQUEST_COMMIT(T,v),  for  T  an  access  to  X 

We  give  a  recursive  definition  for  well-formedness  of  schedules  of  object  M(X).  Namely,  the  empty 
schedule  is  well-formed.  Also,  if  a  =  a'lr  is  a  sequence  of  operations  of  object  X,  then  o  is  well-formed 
provided  that  or’  is  well-formed  and  the  following  hold. 

•  If  is  CREATE(T),  then 

(i)  there  is  no  CREATE(T)  event  in  o’. 

•  If  TT  is  a  REQUEST _  COMMIT  for  T,  then 

(i)  there  is  no  REQUEST _ COMMIT  event  for  T  in  a',  and 

(ii)  CREATE(T)  occurs  in  a'. 

•  If  TT  is  INFORM_COMMIT_AT(X)OF(T),  then 

(i)  there  is  no  INFORM_ABORT_ AT(X)OF(T)  event  in  a’,  and 

(ii)  if  T  is  an  access  to  X,  then  a  REQUEST^ COMMIT  event  for  T  occurs  in  a’. 

•  If  jr  is  INFORM_ABORT_AT(X)OF(T),  then 

(i)  there  is  no  INFORM _ COMMIT _AT(X)OF(T)  event  in  o’. 

A  state  8  of  M(X)  consists  of  the  following  five  components;  s.write-lockholders,  s.read-lockholders, 

s.create_ requested,  and  s.run,  which  are  sets  of  transactions,  and  s.map,  which  is  a  function  from  write- 

lockholders  to  states  of  the  basic  object  X.  We  say  that  a  transaction  in  write-lockholders  holds  a 

write-lock,  and  simil^lrly  that  a  transaction  in  read-lockholders  holds  a  read-lock.  We  say  two  locks 

conflict  if  they  are  held  by  different  transactions  and  at  least  one  is  a  write-lock.  The  initial  states  of 

M(X)  are  those  in  which  write-lockholders  —  {T^^}  and  map(Tp)  is  an  initial  state  of  the  basic  object  X, 

and  the  other  components  are  empty.  The  transition  relation  of  M(X)  is  given  by  all  triples  (s'.ff.s) 

satisfying  the  following  pre-  and  postconditions,  given  separately  for  each  n.  As  before,  any  component  of 

s  not  mentioned  in  the  postconditions  is  the  same  in  s  ais  in  s’. 

CREATE(T),  T  an  access  to  X 
Postcondition: 

s.create_ requested  =  s’. create_ requested  U  {T} 

INFORM _  COMMIT  _AT(X)OF(T),  T  T^ 

Postcondition: 

if  T  G  s’. write-lockholders  then 
begin 

s.write-lockholders  =  (s’. write-lockholders  -  {T})  U  {parent(T)} 
s.map(U)  —  s’.map(U)  for  U  6  s.write-lockholders  -  {parent(T)} 
s.map(parent(T))  =  s’.map(T) 
end 

if  T  6  s’. read-lockholders  then 
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begin 

s.read-lockholders  =  {s’.read-lock.holders  -  {T})  U  {pareni{T)} 
end 


lNTORM_ABORT_AT(X)OF(T),  T 
Postcondition: 

s.write-lockholders  =  s’.write-lockholders  -  descendants(T) 
s.read-lockholders  =  s’.read-lockholders  -  descendants(T) 
s.map(U)  =  s’.map(U)  for  all  U  €  s.-write-lockholders 


REQUEST_COMMIT(T,v)  for  T  a  write  access  to  X 
Precondition: 

T  €  s’.create_ requested  -  s’. run 

s’.write-lockholdera  U  s’.read-lockholders  C  ancestors(T) 
there  are  states  t,  t’  of  basic  object  X  so  that 

(s’ .  niap(least(8’  .write-lockholders)  j  ,CRE  ATE(T),t) 
and  {t,REQUEST_COMMIT(T,v),t’) 
are  in  the  transition  relation  of  basic  object  X 
Postcondition: 

s.run  =  s’. run  U  {T} 

s.write-lockholders  =  s’.write-lockholders  U  {T} 
s.map(U)  =  s’.map(U)  for  aJl  U  €  s.write-lockholders  -  (T} 
s.map(T)  =  t’ 

REQUEST _COMMIT(T,v)  for  T  a  read  access  to  X 
Precondition; 

T  €  s’.create_ requested  -  s’. run 

s’.write-lockholders  C  ancestors(T) 

there  are  states  t,  t’  of  basic  object  X  so  that 

(s’.map(lcast(8’.write-lockholders)),CREATE(T),t) 
and  (t,REQUEST_CO\fMIT(T,v),t’) 
are  in  the  transition  relation  of  basic  object  X 
Postcondition: 

s  run  =  s’. run  U  {T} 

s.read-lockholders  =  s’.read-lockholders  U  {T} 


It  is  clear  that  a  R/W  Locking  object  preserves  well-formedness. 

'I'he  operation  of  a  R/W  Locking  object  should  In-  clear  from  tlic  prc-  and  [•o'^f roiviit ion-  al'oxc 
Indeed,  we  feel  that  the  clarity  and  lack  of  ambiguity  in  describing  the  algorithm  in  this  u:i\  i-  a 
significant  feature  of  our  method,  since  informal  descrijitions  of  algorithms  often  omit  signific.aiit  dct.ail- 

When  an  access  transaction  is  created,  it  is  added  to  the  set  create-rc.iucstcd  \  nsponsi  containinc 
return  value  v  to  an  access  T  can  be  returned  only  if  the  access  has  been  requesti  d  but  not  >ei  respond' ,| 
to,  every  holder  of  a  conflicting  lock  i.s  an  ancestor  of  T.  and  v  is  a  \  ,ilue  that  can  !"■  ii  iurned  b\  ba-ic 
object  X  in  the  response  to  T  from  a  state  obtained  by  performing  f  b’b  XTICP'  m  itie  -i.-iie  ili:ii  i-  ilu 
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value  of  map  at  the  least  member  of  write-lockholders.  When  a  response  is  given,  the  access  transaction 
is  added  to  run  and  granted  the  appropriate  lofk,  and  if  the  transaction  is  a  write  access,  the  resulting 
state  is  stored  as  map(T).  If  the  transaction  is  a  read  access,  no  change  is  made  to  the  stored  state  of  the 
basic  object  X,  i.e.  to  map. 

When  a  R/W  Locking  object  is  informed  of  the  abort  of  a  transaction,  it  removes  all  locks  held  by 
descendants  of  the  transaction.  When  it  is  informed  of  a  commit,  it  passes  any  locks  held  by  the 
transaction  to  the  parent,  and  also  passes  the  version  stored  in  map,  if  there  is  one.* 

We  introduce  some  terms  to  describe  what  M(X)  knows  about  commits  and  aborts  of  transactions.  If  q 
is  a  sequence  of  operations  of  M(X),  T  is  an  access  to  X,  and  T’  is  an  ancestor  of  T.  we  say  that  T  is 
committed  at  X  to  T’  in  a  if  a  contains  a  subsequence  0  consisting  of  an 

INFORM _ COMMIT _ AT(X)OF(U)  event  for  every  U  that  is  an  ancestor  of  T  and  a  proper  descendant 

of  T’,  arranged  in  ascending  order  (so  the  IN'FORM_ COMMIT  for  parent(U)  is  preceded  by  that  for  U). 
If  a  is  a  well-formed  sequence  of  operations  of  M(X),  T  is  an  access  to  X,  and  T'  is  any  transaction,  we 
say  that  T  is  visible  at  X  to  T’  in  a  if  T  is  committed  at  X  to  lca(T,T’),  We  denote  by  visiblej.(o,T)  the 
subsequence  of  a  that  consists  of  operations  of  X  whose  transactions  are  visible  at  X  to  T  in  a.  It  is  clear 
that  visiblejj(o,T)  is  a  well-formed  sequence  of  operations  of  basic  object  X.  We  say  that  a  transaction  T 
is  an  orphan  at  X  in  o  if  INFORM_ ABORT_ AT(X)OF(U)  occurs  in  a  for  some  ancestor  L'  of  T. 

We  collect  here  some  obvious  facts  about  visibility  at  X  of  transactions. 

Lemma  30;  Let  a  be  a  sequence  of  operations  of  M(X)  and  ,3  a  sequence  consisting  of  a 
subset  of  the  events  of  a.  Let  T  be  an  access  to  X  and  T’  a  transaction.  If  T  is  visible  at  X  to 
T’  in  0  then  T  is  visible  at  X  to  T’  in  a. 

Lemma  31:  Let  q  be  a  sequence  of  operations  of  M(X),  and  let  T  and  T'  be  accesses  to  X, 
and  T”  a  transaction.  If  T  is  visible  at  X  to  T’  in  a,  and  T’  is  visible  at  X  to  T”  in  o,  then  T 
is  visible  at  X  to  T”  in  a. 

Lemma  32:  Let  q  be  a  well-formed  sequence  of  operations  of  M(X),  and  let  T  be  an  access 
to  X  and  T’  a  transaction.  If  T  is  visible  at  X  to  T’  in  q,  and  T’  is  not  an  orphan  at  X  in  q, 
then  T  is  not  an  orphan  at  X  in  a. 

Lemma  33:  Let  a  —  a’n  be  a  well-formed  sequence  of  operations  of  M{X). 

1.  If  n  is  a  CREATE(T’)  or  REQLT:ST_COMM1T(T’.v)  event,  and  T  ^  T',  then 
visiblej^(o,T)  =  visiblejj(Q’,T). 

2.  If  TT  is  a  CREATE(T)  or  REQL’EST_COMMIT(T,v)  event,  then  visible^.(o,T)  = 
visiblej^{a’,T)n-. 

3.  If  K  is  INFORM _ COMMIT _AT(X)OF(T’)  with  parent(T’)  an  ances'or  of  T,  then 
visiblej^(a,T)  consists  of  the  events  of  o’  that  are  visible  at  X  to  either  I'  or  T'  in  o'. 

8 

If  the  reader  wishes  to  compare  our  version  of  the  algorithm  with  that  in  |Mo|.  the  following  may  l-e  useful:  Moss  gives  the  name 
"the  associated  state*  for  object  X  and  transaction  T  to  what  we  call  s.map(T’)  wher**  T'  is  the  least  anc^-slor  of  T  in  s. write- 
lockholders,  and  he  calls  s.map{least(s. write-lockholders))  "the  current  slate*  of  X.  Also,  he  removes  a  read-lo-'k  when  the  owner  also 
holds  a  write-lock  (this  is  an  optimization  that  does  not  affect  the  correctness  proof)  Moss  also  allows  internal  Iran^^aclion?  to 
directly  access  objects,  whereas  we  only  allow  leaf  transactions  perform  data  access. 


r 
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4.  If  ir  is  INFORM_COMMIT_AT(X)OF'(T‘)  with  parent('l'’)  not  an  ancfsior  of  T,  or  if 
ir  is  INFORM_ABORT_AT(X)OF(T’),  then  visible^(a,T)  =  visible^.(cy','r). 


f 


Here  are  some  simple  facts  about  the  state  of  M(X)  after  a  schedule  a. 

Lemma  34:  Let  o  be  a  schedule  of  M(X),  and  s  a  state  of  M(X)  reached  by  applying  a  to  an 
initial  state.  Suppose  T  €  s.write-lockholders  and  T’  €  s.read-lockholders  U  s.write-lockholders. 
Then  either  T  is  an  ancestor  of  T’  or  else  T’  is  an  ancestor  of  T. 

Lemma  36:  Let  a  be  a  well-formed  schedule  of  M(X),  and  s  a  state  of  M(X)  reached  by 
applying  a  to  an  initial  state.  Let  T  be  an  access  to  X  such  that  REQUEST _COMMlT(T,v) 
occurs  in  a  and  T  is  not  an  orphan  at  X  in  a,  and  let  T’  be  the  highest  ancestor  of  T  such  that 
T  is  committed  at  X  to  T’  in  a.  Then  if  T  is  a  write  access.  T'  must  be  a  member  of  s.write- 
lockholders,  while  if  T  is  a  read  access,  T’  must  be  a  member  of  s.read-lockholders. 


Given  any  well-formed  sequence  0  of  operations  of  M(X)  let  essence(/J)  denote  the  sequence  obtained 
from  write(^)  by  placing  a  CREATE(Lf)  event  immediately  preceding  a  REQUEST_COMMIT(U,u) 
event.  Since  0  is  well-formed,  essence(/9)  consists  of  a  subset  of  the  events  of  0  and  is  well-formed.  Clearlv 
0  and  essence(/9)  are  write-equal. 

The  following  lemma  shows  how  the  results  of  operations  visible  at  X  to  T  are  recorded  in  the  state  of 


-■a 

lX 


M(X). 

Lemma  36:  Let  a  be  a  well-formed  schedule  of  M(X)  and  s  a  state  of  M(X)  reached  by 
applying  a  to  an  initial  state.  If  T  is  a  transaction  that  is  not  an  orphan  at  X  in  ft,  then  3  — 
essence(vi8iblej^(ft,T))  is  a  well-formed  schedule  of  the  basic  object  X.  Furthermore,  when  3  is 
applied  to  an  initial  state  of  X,  it  can  leave  X  in  the  state  s.map(T’)  where  T'  is  the  least 
ancestor  of  T  such  that  T’  6  s.write-lockholders. 

Proof:  We  use  induction  on  the  length  of  a.  The  basis  case  is  trivial,  so  let  ft  ft'?:.  Let  s' 
denote  a  state  of  M(X)  after  applying  o’  such  that  (s’,?r,s)  is  a  step  of  M(X).  There  arc  five 
cases. 

(1)  a-  is  CREATE(U)  for  an  access  U  to  X. 

If  U  =  T  then  visible^(a,T)  =  visiblejj(a’,T)a,  while  otherwise  visiblej.(o,T)  —  visible,^(ft’,T) 
In  either  case  0  ~  essence(visiblejj(ft,T))  =  essence(visible^(o’,T))  Also  s'.write-lockholders 
=  s.write-lockholders  and  s’. map  =  s.map,  so  the  induction  hypothesis  implies  that  i  is  a 
well-formed  schedule  of  X  that  can  leave  X  in  state  s’.map(T')  -  s.map(T')  when  .a;)plied  to 
an  initial  state. 


(2)  TT  is  REQUEST _COMMlT{LJ,v)  for  U  a  read  access  to  X. 

If  U  —  T  then  visible^(a,T)  ~  visiblej.(a’,T)n',  while  otherwise  visible^(a ,T)  —  visihle^lo  .T) 


.\lso  s' write- 


I'kho 


In  either  case  0  =  essence(vi.siblej^(ft,T))  ^  es,sence(visil)lc^(fi '  I 
=  s.write-lockholders  and  s’. map  s.map,  so  the  imluction  hypothesis  implies  that  3  is  a 
well-formed  schedule  of  X  that  can  leave  X  in  state  s'.map(T')  s  [iiap(T')  when  .ip|died  to 
an  initial  state. 

(3)  TT  is  REQUEST _C'OMMrr(U,v)  for  U  a  write  access  to  X 
We  consider  separately  the  cases  U  ^  -  T  and  U  ^  T. 

If  U  =  T  then  T  €;  s  wiitc-loekholdels  .so  1'  1  l.<  I  I  deiioli  I  hi  |i  a.--l  .imesloi  i.f  1'  in 

s’.write-lockholders.  Let  0’  essence(visiblej^((»  .T))  H\  the  in  lu.  iion  hypoihe>is,  3'  i-  a 
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well-formed  schedule  of  X  that  can  leave  X  in  the  state  s’.map(T”)  when  applied  to  an  initial 
state.  Now  0  =  /9’CREATE(I’)7r:  by  the  definition  of  M(X),  /9’CREATE(U)7r  is  a  (well- 
formed)  schedule  of  X,  and  applied  to  an  initial  state  of  X  it  can  leave  X  in  the  state  s.map(T). 
If  U  ^  T,  s’.write-lockholders  =  s.write-lockholders  -  {U},  so  T’  is  also  the  least  ancestor  of  T 
in  s’.write-lockholders,  and  s’.map(T’)  =  s.map(T’).  Also,  visiblej^(Q;,T)  =  visiblej.(a’,T)  so  /J 
=  essence(visiblejj(a,T))  =  essence(visiblej^(or’,T)).  The  desired  result  follows  immediately 
from  the  inductive  hypothesis. 

(4)  n  is  INFORM  _  COMMIT  _AT(X)OF(U) 

The  discussion  is  divided  into  subcases,  depending  on  the  relation  of  T  and  U  in  the 
transaction  tree. 

(i)  U  is  an  ancestor  of  T. 

Now  visible^(a,T)  =  visiblej^(a’,T),  so  ^  —  essence(visible^(a’,T)).  If  U  is  the  least  ancestor  of 
T  in  s’.write-lockholders  then  by  the  definition  of  M(X),  T’  must  be  parent(U)  and  s.map(T’) 
=  s’.map(U),  while  if  U  is  not  the  least  ancestor  of  T  in  s’.write-lockholders  then  T’  must  be 
the  least  ancestor  of  T  in  s’.write-lockholders  and  s.map(T’)  =  s’.map(T’).  In  either  case, 
s.map(T’)  is  s’.map(T”),  where  T”  is  the  least  ancestor  of  T  in  s’.write-lockholders.  The 
desired  result  follows  immediately  from  the  inductive  hypothesis. 

(ii)  U  is  not  an  ancestor  of  T,  but  parent{U)  is  an  ancestor  of  T. 

Here  we  give  separate  arguments,  depending  on  whether  U  is  in  s’.write-lockholders  or  not.  If 
U  6  s’.write-lockholders  then  Lemma  34  implies  that  no  ancestor  of  T  that  is  a  strict 
descendant  of  parent(U)  can  be  in  s’.write-lockholders.  The  definition  of  M{X)  therefore  shows 
that  T’  =  parent(U)  and  that  s.map(T’)  =  s’.map(U).  Also  we  note  that  visiblej^(a’,U)  is 
write-equal  to  visiblej^(o,T),  since  any  write  access  (for  which  a  REQUEST  _ COMMIT  event 
occurs  in  a)  that  is  committed  at  X  to  an  ancestor  of  T  in  o’  must  be  committed  at  X  to 

parent{U)  in  o’  and  thus  visible  at  X  to  U  in  o  (otherwise  by  Lemma  35  some  ancestor  of  T 

that  is  a  proper  descendant  of  parent(U)  would  be  in  s’.write-lockholders).  Thus  0  — 
essence(visiblejj(a,T))  =  essence(visiblej^(o’,U)).  By  the  induction  hypothesis,  ^  is  a  well- 
formed  schedule  of  X  which,  when  applied  to  an  initial  state  of  X,  can  leave  X  in  state 

s’.map(U)  =  s.map(T’).  On  the  other  hand,  if  U  s’.write-lockholders  then  s.write- 

lockholders  =  s’.write-lockholders  and  s.map  =  s’. map.  Also  visiblejj(o’,T)  is  write-equal  to 
visible^(o,T).  This  is  true  because  any  operation  visible  at  X  to  T  in  q  is  either  visible  at  X  to 
T  in  o’  or  else  is  an  operation  of  an  access  that  is  committed  at  X  to  U  in  o’,  and  any  write 
access  (for  which  a  REQUEST _ COMMIT  event  occurs  in  o’)  that  is  committed  at  X  to  U  in 
o’  must  be  committed  at  X  to  parent(U)  (and  hence  visible  at  X  to  T)  in  o’,  by  Lemma  35  and 
the  assumption  that  U  s’.write-lockholders.  Thus  0  =  essence(visible^(Q,T))  = 
essence(visible^(o’,T)).  By  the  induction  hypothesis,  0  \s  s  well-formed  schedule  of  X  that, 
when  applied  to  an  initial  state  of  X,  can  leave  X  in  the  state  s'.map(T’)  =  s.map(T’). 

(iii)  parent(U)  is  not  an  ancestor  of  T. 

Then  visiblej^(o,T)  =  visible^(o’,T),  so  0  ~  essence(vi.siblej^(Q’,T).  Also  T’  is  the  least 
ancestor  of  T  in  s’.write-lockholders  and  s’.map(T’)  =  s.map(T’).  The  desired  result  follows 
immediately  from  the  inductive  hypothesis. 

(5)  n  is  INFORM  _/VBORT_AT(X)OF(U). 

Then  visiblejj(o,T)  =  visiblejj(o',T),  so  0  —  e8sence(visiblejj(Q,T))  =  essence(visiblej.(Q’,T)). 
Also  since  T  is  not  an  orphan  at  X,  U  is  not  an  ancestor  of  T.  Thus  T’  is  the  least  ancestor  of 


T  in  s’. write- lockholders  and  s’.map(T’)  =  s.map(T’).  The  desired  result  follows  immediately 
from  the  inductive  hypothesis.  □ 

A  consequence  of  this  is  the  following  lemma,  which  explains  a  sense  in  which  M(X)  is  a  resilient  variant 
of  the  basic  object  X. 

Lemma  37:  Let  q  be  a  well-formed  schedule  of  M(X)  and  T  a  transaction  that  is  not  an 
orphan  at  X  in  a.  Then  visiblejj(a,T)  is  a  well-formed  schedule  of  the  basic  object  X. 

Proof:  We  prove  that  visiblejj(a,T}  is  a  schedule  of  X  by  induction  on  the  prefixes  of 
visiblejj(a,T).  The  base  case  is  trivial.  So  consider  an  event  n  in  visiblej^(a,T),  and  the  prefix 
/?  of  visible^(a,T)  ending  with  tt.  Let  ^  —  3't;.  By  the  inductive  hypothesis  5’  is  a  well-formed 
schedule  of  X.  We  must  show  that  is  well-formed  and  that  it  is  a  schedule  of  X.  Since  tr  is 
visible  at  X  to  T  in  o,  so  is  any  operation  of  the  same  access.  Since  a  is  well-formed,  it  follows 
that  all  the  requirements  of  operations’  presence  or  absence  in  l3  are  satisfied,  to  permit  us  to 
deduce  that  j3  is  well-formed  from  Lemma  3.  If  n  is  a  CREATE  event  it  follows  from  the 
Input  Condition  on  all  I/O  automata  that  jr  is  enabled  after  /3\  and  thus  that  is  a  schedule 

of  X,  so  supptose  that  n  is  REQUEST _ COMMIT(U,u).  Consider  vi.siblej^(7’,U)  where  7  =  7'r 

is  the  prefix  of  a  ending  with  n.  Let  s’  denote  the  state  of  M(X)  immediately  before  rr  occurs, 
and  let  U’  denote  the  least  ancestor  of  U  in  s’.write-Iockholders.  By  Lemma  36,  <p  — 
essence(visiblej^(7’,U))  is  a  well-formed  schedule  of  X  that  can  leave  X  in  the  state  s’.mapfl.") 
when  applied  to  an  initial  state.  By  the  preconditions  for  the  operation  n  of  M(X), 
(j)CREATE(U)jr  is  a  schedule  of  X,  which  is  well-formed  since  no  operations  of  the  access  U 
occur  in  the  well-formed  sequence  0. 

We  now  show  that  0'  and  <^CREATE(U)  are  equieffective.  Since  each  is  a  well-formed 
schedule  of  X,  it  suffices  by  Lemma  29  to  show  that  they  are  write-equal.  Now  dCRE.\TE(Ul 
and  visiblejj(7’,U)  are  write-equal,  so  we  need  only  show  that  visiblej.(7’,U)  and  0'  are  wriie- 
equal.  Since  U  is  visible  at  X  to  T  in  a,  any  access  visible  at  X  to  U  in  7’  must  be  visible  at  X 
to  T  in  a,  so  the  events  in  visible^(7’,U)  are  a  subset  of  the  events  in  3'.  Now,  by  the 
preconditions  for  w  as  an  operation  of  M(X)  every  element  of  s’.write-Iockholders  is  an  ancestor 
of  U.  So  if  REQUEST_COMMlT(V,v)  occurs  in  0'  for  a  write  access  y  to  X,  then  Lemma  35 

implies  that  V  must  be  committed  at  X  to  lca(V,U)  in  7'  (since  V  is  not  an  orphan  at  X  in  7', 

as  it  is  visible  at  X  to  T  in  a).  Thus  V  is  vi.sible  at  X  to  L'  in  7’,  so 

REQUEST_COMMIT(V,v)  occurs  in  visiblejj(7’.U).  Also  all  REQUEST  _  COMMIT  events 
for  write  accesses  in  visiblej^(7’,U)  occur  in  the  same  order  as  in  a,  and  similarly  the 

REQUEST _ COMMIT  events  for  write  accesses  in  3'  occur  in  the  same  order  as  in  a.  Thus 
visiblej^(7’,U)  and  0'  are  write-equal,  completing  the  proof  that  (iCREATE(U)  and  3'  arc 
equieffective. 

Since  <;''CREATE(U)7r  is  a  well-formed  schedule  of  X  and  3  -  -  3'n  is  well-formed,  the 
definition  of  equieffective  implies  that  0  is  a  well-formed  schedule  of  X.  as  required  Thus,  by 
induction,  visiblejj(Q,T)  is  a  well-formed  schedule  of  X.  □ 

5.2.  Generic  Scheduler 

The  generic  scheduler  is  a  very  nondetcrminislic  automaton,  ll  pa.sse>  requests  for  the  creation  of  miI'- 
transactions  or  accesses  to  the  appropriate  recipient,  pas.ses  responses  ha<  k  to  the  caller  and  informs 
ohp’Cts  of  the  fate  of  transactions,  but  it  may  delay  such  messages  for  aitutrary  lengtlis  oi  time  01 


unilaterally  decide  to  abort  a  subtransaction  which  has  been  created.  Moss  [Mo]  devotes  considerable 
effort  to  describing  a  distributed  implementation  of  the  scheduler  that  copes  with  communication  failures 
and  loss  of  system  information  due  to  crashes,  yet  still  commits  a  subtransaction  whenever  possible.  These 
concerns  are  orthogonal  to  the  correctness  of  the  data  management  algorithms  and  we  do  not  address 
them  here.® 

The  generic  scheduler  has  nine  operations: 

Input  Operations: 

REQUEST  _  CREATE(T) 

REQUEST_COMMIT(T,v) 

Output  Operations; 

CREATE(T) 

COMMIT(T), 

ABORT(T),  T  ^  Tq 
REPORT_COMMIT(T,v),  T  T^ 

REPORT  _ABORT(T),  T  yS  T^ 

INFORM  _  COMMIT  _AT(X)OF(T),  T 
INFORM  _  ABORT  _AT(X)OF(T),  T 

These  play  the  same  roles  as  in  the  serial  scheduler,  except  for  the  INFORM_ COMMIT  and 
INFORM_ABORT  operations,  which  pass  information  about  the  fate  of  transactions  to  the  R/W 
Locking  objects. 

Each  state  s  of  the  generic  scheduler  consists  of  six  sets:  s.create_ requested,  s. created, 

s.commit_ requested,  s. committed,  s. aborted  and  s. returned.  The  set  s.commit_ requested  is  a  set  of 
(transaction, value)  pairs,  and  the  others  are  sets  of  transactions.  All  are  empty  in  the  initial  state  except 
for  create _ requested,  which  is  {T^j}. 

The  operations  are  defined  by  pre-  and  postconditions  as  follows: 

REQUEST  _CREATE(T) 

Postcondition: 

s.create_  requested  =  s’.create_ requested  U  {T} 

REQUEST  _COMMIT(T,v) 

Postcondition; 

s.commit_ requested  =  s’.commit_requested  U  {(T,v)} 

CREATE(T),  T  a  transaction 
Precondition: 

T  G  s’.create_ requested  -  s’. created 
Postcondition: 


®The  generic  scheduler  is  very  similar  to  the  weak  concurrent  controller  of  |LM|.  It  differs  slightly  in  the  names  of  its  operations, 
in  the  separation  of  return  and  report  operations,  and  in  the  conditions  under  which  CREATE  operations  are  permitted  to  occur. 


s. created  =  s’. created  U  {T} 


COMMIT(T),  T  7^  T„ 

Precondition: 

{T,v)  E  s’.commit_ requested  for  some  v 
T  s’. returned 

children(T)  D  s’. create_ requested  C  s’. returned 
Postcondition: 

s. committed  =  s’. committed  U  {T} 
s. returned  =  s’. returned  U  {T} 

/\BORT(T),  T  7^  Tq 
Precondition: 

T  E  s’.create-requested  -  s’. returned 
Postcondition: 

s. aborted  =  s’. aborted  U  {T} 
s. returned  =  s'. returned  U  {T} 

REPORT_COMMIT(T,v),  T  7^ 

Precondition. 

T  E  s’. committed 

(T,v)  E  s’.commit_ requested 

REPORT _.M30RT(T),  T  7^ 

Precondition: 

T  E  s’. aborted 

I.\FORM_COMMIT_AT(X)OF(T),  T  7^  T,, 

Precondition: 

T  E  s’. committed 

INFORM  _ABORT_AT(X)OF(T).  T  7-^ 

Precon'litioii 

T  E  aborted 

The  followii,^  lemma  relates  the  stale  of  the  generic  .'.chediih-r  to  il.s  schedule 

Lemma  38:  Let  o  be  a  sche<lule  of  the  geturic  scheduler,  and  let  s  be  a  state  which  can 
result  from  applying  a  to  the  initial  'i.ate  s^^  I'lien  the  following  conditions  are  true 

1.  T  is  in  s.create_  requested  exactly  if  o  contains  a  REQIE.^T  _C’HlC.\TE(Tj  e\ent. 

2.  T  is  in  s. created  exactly  if  q  contains  a  f  HlhAThii  r)  event 

.3.  (T,v)  is  in  s. commit  _  requested  exactly  if  r»  contains  a  l\KQl’KS'r_CO.\IMrr(  r,\  ) 
event. 

4  T  is  in  s. committed  exactly  if  o  conl.ain.s  a  ('OM.Ml'ri  P)  e\i-nt 
•a.  T  IS  in  s. aborted  exactly  if  o  contains  an  \IU)RT(T)  event 

6  s  returned  =  .s. committed  U  s  aborteil 

7  s. committed  n  .s. aborted  9 

.‘\n  obvious  but  important  property  of  the  generic  scheduler  is  given  l  x  the  next  lemma. 

Lemma  30:  If  o  Is  ,1  .schedule  of  the  generic  s<  liediih  I  then  o  colilains  al  most  one  la  l  urn 


event  for  each  transaction  T. 


5.3.  R/W  Locking  Systems 

The  composition  of  transactions  with  R/W  Locking  objects  and  the  generic  scheduler  is  called  a  R/\V 
Locking  system,  and  its  operations  and  schedules  are  called  concurrent  operations  and  concurrent 
schedules,  respectively.**^  A  sequence  a  of  concurrent  operations  is  said  to  be  well- formed  provided  that 
its  projection  at  every  transaction  and  R/W  Locking  object  is  w'ell-formed.  The  following  lemma  is 
proved  in  the  same  way  as  Lemma  8. 

Lemma  40:  If  a  is  a  concurrent  schedule,  then  a  is  well-formed. 


The  following  lemma  is  straightforward. 

Lemma  41:  Let  a  be  a  concurrent  schedule.  If  T  is  a  transaction  that  is  not  an  orphan  in  a 
and  T’  is  visible  to  T  in  a,  then  T’  is  not  an  orphan  in  a. 

Note  that  if  a  is  a  concurrent  schedule  then  any  INFORM_COMMIT_AT(X)OF(T)  is  preceded  by  a 
COMMIT(T)  event  (by  the  scheduler  preconditions)  and  similarly  any  lNFORM_.‘VBORT_.\TiX)OF(T) 
is  preceded  by  ABORT(T).  Thus,  if  T  is  visible  at  X  to  T’  in  a  then  T  is  visible  to  T’  in  a,  and  if  T  is  an 
orphan  at  X  in  a  then  T  is  an  orphan  in  a.  Thus,  visiblej^{o,T)  is  a  subsequence  of  visible(o ,T)|X  when 
a  is  a  concurrent  schedule. 

Two  important  properties  of  R/W  Locking  systems  are  given  next. 

Lemma  42:  Let  a  =  a’tr  be  a  concurrent  schedule  where  n  is  REQLTiST_CRE.'kTE(T’), 
COMMIT(T’)  or  ABORT(T’)  for  a  child  T’  of  T.  Then  a’  does  not  contain  a  CONfMlT(T) 
event. 

Lemma  43:  Let  a  be  a  concurrent  schedule,  T  a  transaction  that  is  not  an  orphan  in  a  and 
M(X)  a  R/W  Locking  object.  Then  visible(a,T)|X  is  a  well-formed  schedule  of  basic  object  X. 

Proof:  Let  S  denote  the  set  of  transactions  with  COMMIT  events  in  a.  Construct  a 
sequence  0  by  appending  to  a  a  sequence  of  INFORM _ COMMIT _.\T(X)OF(U)  events,  where 
the  U  give  a  post-order  traversal  of  S.  Since  a  contains  a  COMMIT(U)  event  for  each  U  in  S,  3 
is  a  concurrent  scliedule,  and  by  Lemma  37  visiblej^{^,T)  is  a  well-formed  schedule  of  X.  Since 
the  INFORM _ COMMIT _AT(X)OF(U)  events  at  the  end  of  0  are  in  ascending  order,  and 
occur  for  every  U  that  has  committed  to  T  in  0,  visible.^(d,T)  =  visible(5,T)|X.  Also 
visible(/3,T)  =  visible(a,T)  since  INFORM __ COMMIT  operations  have  no  influence  on  what 
transactions  are  visible  to  T.  Thus  visible(a,T)|X  is  a  well-formed  schedule  of  X.  □ 


10 


Note  that  this  usage  differs  from  that  in  1LM|. 
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6.  The  Proof  of  Serial  Correctness 

Wp  prove  that  a  R/W  Locking  system  generates  schedules  that  are  serially  correct  for  each  non-orphan 
transaction  T,  by  taking  a  concurrent  schedule  a,  extracting  the  subsequence  visibie(a,T)  of  events  whose 
effects  might  have  been  detected  by  T,  and  then  rearranging  the  operations  in  this  to  give  a  serial 
schedule  The  rearrangements  permitted  are  those  that  transform  one  sequence  into  a  write-equivalent** 
one. 

S.l.  Write-Equivalence 

Two  sequence'  of  serial  operations,  7  and  7’,  are  write -equivalent  if 

1.  they  contain  the  same  events, 

2.  for  each  transaction  U,  7(U  =  7’|U,  and 

3.  for  each  basic  object  X,  7|X  and  7’|X  are  write-equal  sequences  of  operations  of  X. 

Thus,  the  rearrangements  allowed  include  interchanging  the  order  of  two  events  of  different  transactions 
or  objects,  and  also  interchanging  the  order  of  events  of  a  single  object,  provided  that  they  are  not  both 
REQUEST  _  COMMITS  for  write  accesses.  By  the  semantic  conditions  of  Section  4.3,  such 
rearrangements  at  objects  are  such  that  the  difference  between  the  orders  is  not  detectable  by  any  later 
operations  of  that  object.  This  property  is  expressed  by  the  following  lemma. 

Lemma  44:  If  a  and  l3  are  write-equivalent  sequences,  and  ojX  and  ,?1X  are  well-formed 
schedules  of  X  for  each  basic  object  X,  then  ctlX  and  are  e  piieffective  sequences. 

When  we  use  this  lemma,  a  and  0  will  each  be  either  a  serial  schedule  or  the  subsequence  of  a 
concurrent  schedule  visible  to  a  transaction,  and  so  the  hypothesis  that  a|X  and  /J|X  are  well-formed 
schedules  of  X  will  be  satisfied  for  all  basic  objects  X,  by  Lemmas  8  and  43. 

Write-equivalence  is  obviously  an  equivalence  relation  We  h.ns  e  some  si  r. tight  forw.-ird  results 

Lemma  45:  If  a  and  0  are  .sequences  of  opcration.s  that  are  write-equivalent,  then  .to  is 
write-equivalent  to  for  any  sequence  <5  of  operations. 

Lemma  48:  If  a  and  0  are  serial  schedules  that  are  write-equivalent  and  at?  is  a  serial 
schedule  then  0<t)  is  a  serial  schedule 

Proof:  From  Lemma  45  we  .see  that  for  any  non-access  transaction  I',  /^0|r  oc>|l’  wlticli 
is  a  schedule  of  U,  since  q0  is  a  serial  schedule  For  each  basic  object  X.  b\  Lemma  4  4  o\\  is 
equ  ■’ffective  to  0\S.,  so  is  equieffective  to  <io|X,  and  since  o.^jX  is  a  .schedule  of  X,  so  !•< 

0<l>\X..  Thus,  we  need  only  show  that  fl<i>  is  a  schedule  of  the  serial  scheduler  For  3  this  is  a 
hypothesis  of  the  lemma,  and  events  in  4>  are  enabled  at  the  serial  scheduler,  VHcausc  by 
Lemma  7  the  preconditions  of  operations  of  the  serial  scheduler  depend  only  on  the  presence  or 
absence  of  operations  in  the  preceding  schedule,  not  on  the  or<ler  of  those  events.  □ 


^Shis  notion  is  a  generalization  of  e.^-iiv aif  n-  ''  a.'  lii  I..M 
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0.2.  A  Technical  Lemma 

In  tills  subsection,  we  prove  a  resnl*  similar  to  l.emma  ffl,  for  use  in  the  proof  of  Lemma  48  in  Section 
6.3. 

Lemma  47:  Let  o  be  a  concurrent  schedule,  and  let  T  and  T’  be  two  non-orphan 
transactions  with  T’  visible  to  T  in  a.  Let  3  and  0^  be  serial  schedules  such  that  3  is  write- 
equivalent  to  visible(a,T)  and  0^  is  write-equivalent  to  visible(a,T').  Then  7  =  0^{0  -  is  a 
serial  schedule  that  is  write-equivalent  to  visible(a’,T). 

Proof:  First  we  prove  that  0’  =  visible(;9,T’)  is  write-equivalent  to  0^.  By  Lemma  15  and 
Lemma  13,  0'  and  0^  contain  the  same  events.  For  any  basic  object  X.  write(,f’|X) 
write(/9j|X)  since  REQUEST _ COMMIT  events  for  write  accesses  to  X  occur  in  3'  in  the  same 
order  as  they  occur  in  0,  which  is  the  same  as  the  order  they  occur  in  a,  which  is  the  same  as 
the  order  they  occur  in  0^  For  any  transaction  U  that  is  visible  to  T'  in  o  (and  hence  in  0). 

/3’|U  =  0\\J  =  a|U,  by  Lemma  14  and  write-equivalence,  and  similarly  /JJf  -  '>|l'  On  the 
other  hand,  if  U  is  not  visible  to  T’  in  a,  d’lU  and  are  both  empty. 

By  Lemma  19,  0'(0  -  0’)  is  a  serial  schedule.  Since  0-0'  —  0  -  0^  (as  0'  and  0^  contain  the 
same  events)  and  0’  is  write-equivalent  to  0^,  we  deduce  from  Lemma  46  that  7  is  a  .serial 
schedule. 

Next,  we  prove  that  write(visible(a,T’)|X)  is  a  prefix  of  write(visible(a,T)|X)  for  any  object 
X.  Suppose  that  visible(a,T)  contains  a  REQUEST_COMMlT(U,u)  event  for  a  write  access  1' 
to  X  that  is  not  in  visible(a,T’).  Let  REQUEST _COMMIT(U',  11')  be  a  subsequent  event, 
where  U’  is  a  write  access  to  X  that  is  visible  to  T  in  o.  We  must  show  that  I’’  is  not  visible  to 
T’  in  a.  Consider  the  prefix  5  of  a  that  precedes  the  REQUEST _CON'rMIT(U’,u’),  and  let  s 
denote  the  state  of  the  R/W  Locking  object  M(X)  after  6.  If  we  denote  by  I'"  the  highest 
ancestor  of  U  to  which  U  has  committed  in  a,  then  U”  is  a  proper  descendant  of  lca(l'.T'), 
since  U  is  not  visible  to  T’  in  a.  Then  the  highest  ancestor  of  U  to  which  U  is  committed  at  X 
in  8  must  be  a  descendant  of  U”,  and  so  by  Lemma  35  some  descendant  of  U”  is  in  s.write- 
lockholders.  By  the  preconditions  for  the  operation  REQLlEST_COMMlT(l'’,u’)  of  M(X),  L’’ 
must  be  a  descendant  of  U”,  and  therefore  U’  is  not  committed  in  a  to  lca(U '.T')  -  lca(l  ’.T  ) 

=  lca(U,T’),  Therefore  U’  is  not  visible  to  T’  in  a,  establishing  that  wriie(visible(a.T')|X)  is  a 
prefix  of  write(visible(Q',T)|X). 

Now  we  show  that  7  is  write-equivalent  to  0.  They  clearly  contain  the  same  event-,  since 
every  event  of  0^  occurs  in  0  (because  any  operation  visible  to  T’  in  o  is  also  visible  to  T  in  n 
by  Lemma  12).  If  F  is  a  basic  object,  write(idj|P)  wriie(vi.sibleif».T  )|l’)  is  a  prefix  of 
write(visible(o,T)|P)  write(iJ|P),  so  that  write(7jF’)  =  (write(.'lJP))(wnie(.llP)  -  write|  .-(JF)) 

=  write(/J|P).  If  P  is  a  transaction  that  is  visible  to  T’  in  o  then  .'^j|P  visible(,i  'I  )'P 
o|P  =  visible(a,T)|P  -  0\P.  so  7IP  -  {i'^,|P)(-^|P  -  ^,|P)  '^|f’  (bi  the  other  hand  if  I'  is  a 

transaction  not  visible  to  T’  in  o  then  »1||P  is  empty,  so  trivially  “jIP  .:y|P 


Since  7  is  write-equivalent  to  0,  it  is  write-equivalenl  to  visible(f»,T) 
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0.3.  The  Mein  Results 

V\'e  are  now  ready  to  prove  that  R/W  Locking  systems  are  serially  correct  for  every  transaction  that  is 
not  an  orphan.  We  actually  state  a  stronger  property  that  carries  useful  invariants  through  the 
induction. 

Lemma  48:  Let  a  be  a  concurrent  schedule,  and  T  any  transaction  that  is  not  an  orphan  in 
a.  Then  there  is  a  serial  schedule  0  that  is  write-equivalent  to  visible(a,T). 

Proof:  The  proof  follows  the  outlines  of  that  of  the  main  theorem  of  [LM’.  VV’e  proceed  by 
induction  on  the  length  of  a.  As  before,  let  a  =  or'tr.  We  must  show  that  there  is  a  serial 
schedule  that  is  write-equivalent  to  vi8ible(o',T).  We  can  assume  that  transaction!  tr)  is 
visible  to  T  in  o.  There  are  seven  cases,  and  in  each  we  relate  visible(a,T)  to  visible(o’,r)  for 
one  or  more  transactions  U,  and  build  0  from  serial  schedules  wnte-equivalent  to  visible(a',l'). 

(L)  It  IS  an  output  operation  of  a  non-access  transaction  TV 
Since  T  is  not  an  orphan  in  a’,  the  inductive  hypothesis  implies  the  existence  of  a  serial 
schedule  0'  that  is  write-equivalent  to  visible(Q’.T).  Let  0  =  0'n.  We  will  show  that  3  is  a 
serial  schedule  that  is  write-equivalent  to  visible(o,T).  By  Lemma  1.  to  check  that  3  is  a  serial 
schedule  we  need  only  check  that  0'trlT'  is  a  schedule  of  T’.  However  0’\T'  —  visible(n ’,T)|T' 

=  o’|T’  by  Lemma  14  (since  T’  is  visible  to  T).  Thus  ,d'>r|T’  =  a'jr|T'  =  a|T’,  which  is  a 
schedule  of  T’.  Thus,  d  is  a  serial  schedule. 

By  Lemma  18,  vi8ible(«,T)  =  visible(a’,T)jr  and  since  0'  is  wi  ite-equivalent  to  visible(a’.T). 
we  may  apply  Lemma  45  to  deduce  that  0  is  write-equivalent  to  visible(Qf  T). 

(21  >r  IS  an  output  operation  of  a  R  W  Locking  object  M(X) 

Since  T  is  not  am  orphan  in  o’,  the  inductive  hypothesis  implies  the  existence  of  a  serial 
schedule  0'  that  is  write-equivalenl  to  visible(o',T).  Let  0  =-  0'w.  We  will  show  that  3  i.s  a 
serial  schedule  that  is  write-equivalent  to  visible(o,T).  By  Lemma  1,  to  check  that  is  a  serial 
schedule  we  need  only  check  that  ^’»r|X  is  a  schedule  of  X.  However,  Lemma  44  implies  that 
:^'|X  is  equieffective  to  and  contains  the  same  events  as  visible(Q’’,T)|X.  Now  visible(Q’,T)n’|X 
—  viaible(o’jr,T)lX  =  visible(a ,T)(X,  which  is  a  schedule  of  X  by  Lemma  43.  Thus  by  Lemma 
24,  d'trjX  IS  a  schedule  of  X  1’hus  d  is  a  serial  schedule. 

Since  visible(o,T)  =  visible(o’.T)tr,  0  -  0'7r.  a' d  3'  is  w  riie-equivalent  to  visible(o’,T),  we 
may  apply  Lemma  45  to  deduce  that  0  is  wnte-equivalent  to  visible! cr.T). 

(3)  ms  a  CRKATE(T')  operation 

Then  transaction! »r)  =  T',  and  scr  T  is  visible  to  1'  in  a  H>  w ell-fornu‘dne<,''  and  the 
-cheduler  preconditions,  any  operation  of  a  proper  desiendant  of  1'  must  be  preceded  1,\  a 
REQUEST __ CREATFi  f<e  a  child  of  T’,  and  by  well-formedness  any  operation  of  T'  must 
follow  C'REATFi(T')  Thus,  k  is  the  first  event  whose  transaction  is  a  descendant  of  T',  so  1" 

T  Hy  Lemma  21,  parent(T|  is  not  an  orphan  in  o.  and  hence  in  o  ,  so  the  inductne 
hyjiothesis  implies  the  existence  of  a  serial  schedule  3'  that  is  w  nte-equi\ alent  to 
visible(a',parent(T))  Let  3  3'n  We  will  show  that  3  is  a  serial  schedule  that  is  wnie- 

etjuiv  alent  to  visible(o,T) 

To  show  that  3  IS  a  seri.il  schedule,  we  need  only  check  that  /Ttr  is  a  schedule  of  the  s,.|i,d 
scheduler  If  s'  is  the  state  of  tin-  serial  scheduler  after  an  execution  with  operation  sequence  3', 
we  will  show  that  ir  is  enabled  in  .s'  We  note  that  tt  w-a,-.  enabled  in  the  state  s  ’  of  the  generic 
scheduler  that  arose  from  'he  exei  iitiioi  with  operation  seqm  le  <  ,i'  'i'lm-  fiou;  die 


33 


preconditions  for  »r  in  the  generic  scheduler  and  from  Lemma  38  we  see  that  o’  must  contain 
REQUEST _CREATE(T)  but  not  CREATE(T),  and  since  T  is  not  an  orphan  in  a,  no 
ABORT(T)  event  occurs  in  o’.  These  conclusions  also  hold  for  visible(o’,parent(T))  since 
REQUEST _CREATE(T)  occurs  at  parent(T)  and  any  operation  absent  in  a’  must  be  absent 
from  its  subsequence  visible(Q’,parent(T)).  Since  is  write-equivalent  to  visible(a’,parent(T)) 
it  contains  the  same  events,  and  so  /3’  contains  REQUEST _CREATE(T)  but  no  CREATE(T) 
or  ABORT(T)  event,  and  Lemma  7  shows  that  T  G  s’.create-requested  -  (s’. created  u 
s’. aborted).  Also  for  any  U  G  sibling(T),  if  U  G  s’.created  then  CREATE(U)  occurs  in  .d’  and 
hence  in  visible(o’,parent(T)),  so  U  must  be  visible  to  parent(T)  in  a’,  so  COMMIT(U)  must 
occur  in  a’  and  thus  in  visible(a’,parent(T))  (as  it  has  transaction  parent(U)  =  parent(T)),  and 
so  COMMIT(U)  occurs  in  /S’.  By  Lemma  7,  U  G  s’. returned,  establishing  that  sibling(T)  n 
s’.created  C  s’. returned.  Thus  we  have  checked  that  tt  is  enabled  in  s’,  and  therefore  /?  =  S’tt 
is  a  serial  schedule. 

Since  visible(a,T)  =  visible(Q'’,parent(T))jr,  0  =  fi'n  and  /S’  is  write-equiv^lent  to 
visible(o’,parent(T)),  we  may  deduce  from  Lemma  45  that  /?  is  write-equivalent  to  visible(a.T). 

(4)  jr  is  a  COMMIT(T’)  operation. 

Then  T”  =  parent(T’)  is  visible  to  T  in  a,  since  transaction(rr)  =  T”.  Lemma  42  says  that 
no  COMMIT(T”)  occurs  in  o’,  and  so  T  must  be  a  descendant  of  T”  (since  T  '  is  visible  to  T). 
Also,  by  Lemma  41,  T”  is  not  an  orphan  in  a  and  so  also  T"  is  not  an  orphan  in  o’.  From 
this  and  Lemma  39,  we  deduce  that  T’  is  not  an  orphan  in  o'.  We  distinguish  two  cases, 
depending  on  whether  T  is  a  descendant  of  T’  or  not. 

Assume  first  that  T  is  a  descendant  of  T’.  Then  visible(Q,T)  =  visible(a’,T)ff,  and  by  the 
induction  hypothesis  there  is  a  that  is  serial  and  write-equivalent  to  visible(Q’,T).  Let  $  = 
0’w.  We  show  that  0  is  a.  serial  schedule  that  is  write-equivalent  to  visible(o,T).  To  show  that 
0  is  serial,  we  must  show  that  jr  is  enabled  at  the  serial  scheduler  after  0’ .  The  serial  scheduler 
preconditions  and  Lemma  7  show  that  we  must  prove  that  KLQUEST_COMMIT(T’,v)  occurs 
in  0',  that  no  return  for  T’  occurs  in  0’,  and  that  for  every  child  U  of  T’  with  a 
REQUEST _ CREATE(U)  in  0’  there  is  a  return  event  in  0' .  Since  tr  is  enabled  in  the  generic 
scheduler  after  o’,  each  of  these  is  true  with  a’  replacing  0' .  Since  all  these  operations  are 
visible  to  T  in  o’,  all  these  statements  are  also  true  of  visible(o’,T)  and  thus  of  the  write- 
equivalent  sequence  0’ ,  as  required.  Now  we  note  that  Lemma  45  proves  that  0  =  B’n  is  write- 
equivalent  to  visible(Q,T)  =  visible(o’,T);r. 

In  the  other  case,  when  T  is  not  a  descendant  of  T’,  the  inductive  hypothesis  yields  three 
serial  schedules,  0',  0"  and  q,  that  are  write-equivalent  to  visible(a’,T’),  visible(Q’,T)  and 
visible(a’,T”)  respectively.  Let  0^  =  0'  -  -y  and  0^  =  0"  -  q.  Let  0  —  We  show  that 

0  is  A  serial  schedule  that  is  write-equivalent  to  visible(Q,T).  That  0  is  serial  follows  from 
Lemma  27,  provided  we  can  show  that; 

(4. a)  q/^jTT  is  a  serial  schedule, 

(4.b)  ^0^  is  a  serial  schedule, 

(4.c)  q/3j  =  visible(q/3j,T’), 

(4.d)  q/?2  =  visible(q/32,T), 

(4.e)  q  =  visible(q/3|,T”)  =  visible(q;,3.,,T”)  and 
(4.f)  if  any  basic  object  X  has  an  output  operation  in  /?,,  then  ev 
transparent. 
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preconditions  and  Lemma  7  show  that  we  must  prove  that  REQLTEST_COMMlT(T’,v)  occurs  ; 

in  '10^  for  some  v,  that  no  return  for  T’  occurs  in  -7/?^,  and  that  for  every  child  T  of  T'  with  a  | 

REQUEST_CREATE(U)  in  -^0^  there  is  a  return  event  in  •y0^.  Since  n  is  enabled  in  the  1 

generic  scheduler  after  a’,  each  of  these  is  true  with  a’  replacing  7/9^,  Since  all  these  operations  , 

are  visible  to  T’  in  o’,  all  these  statements  are  also  true  of  visible(a’,T')  and  thus  of  the  write-  ' 

equivalent  sequence  'y0^,  as  required.  Thus  Tf/Sjtr  is  a  serial  schedule.  We  also  note  that  Lemma  1 

45  proves  that  'y0^ir  is  write-equivalent  to  visible(o,T’)  =  visible(a’,T’)7r.  | 

(4.b)  By  Lemma  47,  'y0^  is  serial  (and  write-equivalent  to  visible(Q ’.T)). 

Parts  (4.c)-(4.e)  are  immediate.  ' 

(4.f)  We  prove  that  if  a  basic  object  X  has  an  output  operation  in  0^  then  no  event  in  /i9JX  is 


a  REQUEST _ COMMIT  for  a  write  access.  Suppose  this  were  false.  Then  0^  contains  a 
REQUEST  _COMMIT(Vj,Vj)  for  a  write  access  to  X,  and  0^  contains  a 

REQUEST_COM\nT(V2,v,)  for  V,,  an  access  to  X.  Since  is  visible  in  a  to  T’  but  not  to 

T”,  Vj  must  be  a  descendant  of  T’,  and  not  an  orphan  in  a,  and  must  not  be  committed  at 
X  to  T”  in  a.  By  Lemma  35,  some  descendant  of  T’  is  in  s.write-lockholders,  where  s  is  a  state 
of  M(X)  after  applying  a.  Similarly  must  be  a  descendant  of  some  sibling  U  of  T’  but  not 
committed  at  X  to  T”  in  a,  so  by  Lemma  35,  some  descendant  of  U  is  in  s.readlockholders  U 
s.write-lockholders.  But  these  two  statements  about  lockholders  contradict  Lemma  34. 

Now  we  must  prove  that  0  is  write-equivalent  to  visible(a,T).  Since  any  transaction  visible 
to  T  in  a  is  either  visible  to  T  in  o’  or  visible  to  T’  in  a’  and  if  both  then  it  is  visible  to  T”  in 
a’,  it  is  clear  that  0  and  visible(a,T)  contain  the  same  events.  If  P  is  a  basic  object,  either  0,^ 
contains  no  output  operations  of  P  or  else  no  operation  in  ;?j|P  is  a  REQUEST_ COMMIT  for 
a  write  access.  In  the  first  case  writc(^.,|P)  is  empty,  and  since  writef-y/JjtrlP)  = 
write(visible{o’,T’)|P),  we  have  write(j91P)  =  write(visible(a,T)|P),  In  the  second  ca.se 
write(^jlP)  is  empty,  and  since  write(-)'/92lP)  =  write(visible(a',T)|P),  we  again  have  write(iiP) 
=  write(visible(a,T)|P).  If  P  is  a  non-access  transaction  that  is  not  visible  to  T  in  o,  then  no 
operations  occur  at  P  in  either  0  or  visible(Q,T).  For  P  any  non-access  transaction  that  i.s 
visible  to  T  in  o:,  either  P  is  visible  to  T  in  o’  or  P  is  visible  to  T’  in  a'.  In  the  first  case.  i9„|P 
is  empty  so  ^(P  =  q^j»r|P  =  visible(Q,T’)iP  since  we  saw  above  that  idjtr  and  visible(o  .T') 
are  write-equivalent,  and  visible(o,T’)lP  ==  =  vi.sible(o,T)|P.  Similarly  m  the  second  case 

/9j7r|P  is  empty  and  0\P  =  '10^\F  =  visible(o’.T)|P  =  visible(o .T)iP.  In  every  case,  we  have 
checked  that  yd|P  =  visible{a,T)|P.  Thus  0  and  visible(o .1)  are  write-equivalent. 
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(5)  tr  is  an  ABORT(T’)  operation. 

Then  T”  =  parent(T’)  is  visible  to  T  in  o,  since  transact ion(7r)  T"  Lemma 
COMMlT(T”)  does  not  occur  in  o’  and  so  T  must  be  a  de-cemhint  of  T"  (since  T' 
T).  Also  by  Lemma  41,  T”  is  not  an  orphan  in  o  and  so  also  T"  is  not  an  orphan 
T  is  not  an  orphan  in  a,  T  is  not  a  descendant  of  T'.  Thu'.  the  indurti\e  h\pothe- 
serial  schedules,  0’  and  q,  that  are  write-equivalent  to  visil)h'(a  .T)  and  \ 
respectively.  Let  0^  —  0'  -  7  Let  3  -=  7trJ|.  We  show  that  3  is  a  serial  sch 
write-equivalent  to  visiblejo.T).  That  3  is  xTial  follows  from  I.einma  'J8,  pro' 
show  that: 

(5. a)  7Jr  is  a  serial  schedule, 

(5.b)  7/?|  is  a  serial  srln  dule. 
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(5.c)  =  visible(7/9j,T), 

(5.d)  7  —  visiblp(7,T’')  —  visible(7/9j,T”) 

(5. a)  Since  7  is  a  serial  schedule,  we  must  show  that  tt  is  enabled  at  the  serial  scheduler  after 
7.  The  serial  scheduler  preconditions  and  Lemma  7  show  that  we  must  prove  that 
REQUEST_CREATE(T’)  occurs  in  7,  and  that  no  CREATE(T’)  or  ABORT(T’)  occurs  in  7, 
Since  1:  is  enabled  in  the  generic  scheduler  after  a',  o’  contains  a  REQUEST _CREATE(T’) 
event,  and  since  transaction(REQL'EST_CREATE(T’))  =  T”,  REQUEST_CREATE(T  )  is 
in  visible(a’,T”)  and  hence  in  7.  By  Lemma  39,  T’  is  not  committed  in  o’,  so  that  any 
CREATE(T’)  event  in  o’  is  not  visible  to  T”,  and  so  does  not  occur  in  visible(a’,T”)  and 
hence  does  not  occur  in  7.  By  Lemma  39,  there  is  no  ABORT(T’)  event  in  o’,  so  .\BORT(T’) 
does  not  occur  in  7.  Thus  77r  is  a  serial  schedule.  We  also  note  that  Lemma  45  proves  that  'yn 
is  write-equivalent  to  visible(Q',T')  =  visible(a’,T’)7r,  since  7  and  visible(a’,T’)  are  write- 
equivalent. 

(5.b)  By  Lemma  47,  7/9^  is  a  serial  schedule  (and  it  is  write-equivalent  to  visible(Q’,T)). 

Parts  (5.c)  and  (5.d)  are  immediate. 

Now  we  must  prove  that  is  write-equivalent  to  visible(o,T).  Since  any  transaction  visible 
to  T  in  a  is  visible  to  T  in  o’,  and  either  visible  to  T”  in  o’  or  not,  it  is  clear  that  /?  and 
visible(Q',T)  contain  the  same  events.  If  P  is  a  basic  object,  since  write(7/?JP)  = 
write(visible(a’,T’)|P)  we  have  write(,9|P)  —  write(visible(o,T)|P).  For  P  any  non-access 
transaction,  /9|P  =  7/9JP  =  visible(Q’,T)|P  =  visible(o,T)|P,  since  n-|P  is  empty  and  7/9^  and 
visible(a’,T)  are  write-equivalent.  This  completes  the  demonstration  that  0  and  visible(o,T) 
are  write-equivalent. 

(6)  TT  is  REPORT_COMMIT(T’,v) 

Since  T  is  not  an  orphan  in  o’  there  is  a  serial  schedule  0’  that  is  write-equivalent  to 
visible(Q’,T).  Put  0  =  0'n.  By  the  preconditions  of  the  generic  scheduler  and  Lemma  38, 
REQUEST _COMMIT(T’,v)  and  COMMIT(T’)  occur  in  o’.  Since  the  report  is  in 
visible(Q'’,T),  parent(T’)  is  visible  to  T  in  o’;  thus,  COMMIT(T’),  and  hence 
REQUEST  _COMMlT(T’,v),  are  in  visible(Q’,T).  So  COMMIT(T')  and 

REQUEST_COMMIT(T’,v)  occur  in  0’.  The  serial  scheduler  preconditions  and  Lemma  7 
imply  that  n  is  enabled  after  0'  at  the  serial  scheduler,  and  so  by  Lemma  1  and  Lemma  4.5,  S 
is  a  serial  schedule  that  is  write-equivalent  to  visible{a,T)  =  visible(o',T)7r. 

(7)  w  is  REPORT _ABORT(T’) 

This  is  just  like  case  (6). 

Thus  in  every  case  we  have  produced  a  serial  schedule  0  that  is  wr  'p-pquivalent  to 
visible(o,T).  □ 

Theorem  49:  Every  concurrent  schedule  is  serially  correct  for  every  non-orphan  non-acces.s 
transaction. 

Proof:  Let  T  be  a  transaction  that  is  not  an  orphan  in  the  concurrent  schedule  o  By 
Lemma  48  there  is  a  serial  schedule  0  that  is  write-equivalent  to  \  isihle(it  ,T)  Then  o  F 
visible(o,T)|T  by  Lemma  14,  and  by  write-equivalence,  visi  hle(o.T)IT  ,9|T  □ 

In  particular,  the  external  environment,  modelled  by  T^j,  receives  responses  from  transactions  that 
consistent  with  a  serial  execution. 
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Corollary  60;  Every  concurrent  schedule  is  serially  correct  for  T^. 

7.  Conclusions  and  Further  Work 

We  have  used  I/O  automata  to  provide  clear  formal  description>  of  all  the  components  of  a  rusted 
transaction  system  that  uses  Moss’s  algorithm  to  manage  data.  We  have  shown  how  to  take  any  schednl'- 
of  such  a  system,  extract  a  subsequence  (including  all  the  operations  of  a  given  non-orphan  tran.sactioii ), 
and  rearrange  the  events  in  the  subsequence  to  give  a  write-equivalent  serial  schedule.  Thus  we  have 
demonstrated  that  any  schedule  of  a  R/W  locking  system  is  serially  correct  for  every  non-orphan 
transaction 

This  work  by  no  means  exhausts  the  topic  of  concurrency  control  and  recovery  in  nested  transaoiion 
systems.  Work  is  currently  underway  on  a  number  of  issues  orthogonal  to  the  locking  techniques 
considered  in  this  paper,  for  example  replication  [GL]  and  orphan  elimination  jHLNfVV..  We  also  hope  to 
extend  the  results  of  this  paper  in  several  ways.  One  natural  extension  is  to  locking  protocols  for  abstract 
data  types  that  allow  more  concurrency  than  R/W  locking  by  using  more  semantic  information  about  the 
operations.  Such  protocols  have  been  studied  in  transaction  systems  without  nesting  IWei.  In  generalizing 
these  protocols  to  handle  nested  transactions,  it  appears  that  equieffectiveness  can  be  used  to  provirle  a 
natural  definition  of  commutativity  (or  non-conflict)  between  operations,  which  can  then  be  used  to  prove 
the  correctness  of  an  algorithm  that  generalizes  conflict-based  locking  to  nested  systems. 

Other  aspects  of  real  systems  that  we  have  not  addressed  in  this  paper,  but  expect  to  study  in  the 
future,  are  liveness  properties  and  resilience  to  system  crashes.  We  have  proved  that  any  response  to  ,a 
R/W  locking  system  is  correct,  but  for  a  practical  .system  we  also  need  to  know  that  a  response  will  bi- 
produced  (and,  we  hope,  rapidly  produced  )  Lynch  and  Tuttle  LT|  discu.ss  how  to  express  liveness  re-ult- 
in  terms  of  I/O  automata,  but  phenomena  such  as  deadlock  in  transaction  systems  make  it  difficult  to 
guarantee  strong  liveness  properties.  At  best,  any  guarantees  that  progress  can  be  made  will  be 
probabilistic.  System  crashes  that  cause  information  to  be  lost  (such  as  lock  tables)  are  also  a  nalitx  of 
practical  systems.  We  plan  to  extend  the  model  presented  in  this  pafier  to  describe  rriuslie>.  ami  to 
analyze  algorithms  that  ensure  resilience  to  crashes. 
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